Сообщений в теме: 12

[Case]

Новая статья в Записках тестировщика.

«Парное тестирование»
Совершенно верно, парное тестирование, то есть работа двух тестировщиков в паре над одной задачей и буквально за одной машиной. Если вы не поклонник ХР не спешите сворачивать выпуск — я не буду вас агитировать и пояснять как это здорово или наоборот неудобно, я расскажу почему в работе отдела тестирования некоторые аспекты ХР очень полезны.

Содержание:
Парное тестирование
Зачем нам парное тестирование?
Как на практике?
Поставим эксперимент.
Как построили работу?
Первые результаты.
На чём экономим?
Психологический эффект.
Когда это полезно.

Читать статью полностью: http://tester.com.ua...are_testing.htm

[Spy]

Классный артикл, больше всего понравилось то, что приводится не просто умозаключения, а реальный опыт с "поля боя".

За заботу о новичках тебе отдельное спасибо, а в повседневной практике "парное тестирование" ты на конвеер у себя на работе ставишь или всё зависит от обстоятельств?

[Case]

Заботой о новичках тут не отделаешься :)
Просто так человек значительно активнее входит "в тему", в режим работы.

На конвеер мы ничего не ставим - есть потребность - работаем в парах, нет необходимости/возможности - работаем по одному.

[rlabs]

Пытался недавно в ходе обучения тестеров поставить эксперимент по парному exploratory testing. Не получилось ;-)
То есть отсутствовал момент мотивации, это раз (люди ходили друг к другу советоваться, но в паре работать не хотели); и наличествовал разный уровень подготовки - один участник был уже немного подготовлен, и поэтому априори вел себя как лидер, создавая асимметрию.

Это я, наверное, к тому, что процесс парного тестирования требует весьма неслабой подготовки и постоянной поддержки.

(Обсуждаемую статью еще не читал, но читал по этой теме Кэнера и других классиков)

[Viktor]

Статья хорошая.
Но вот ведь какая штука: ехал я как-то по российскому (без)дорожью, медленно, рассматривая окрестности и наблюдал следующую картину:
Дедок лет 80 при лаживает к одной гнилой досочке другую, что бы хоть как-то более пристойно выглядел его забор.
А теперь идея:
Как застраховаться от подобных случаев? Обучение - обучением, но цель XP - оптимизация использования ресурсов.
Есть ограничения по времени - добавляем людей. Но не приведет ли к этот путь к тому, что человек станет более безответственнен? Будет полагаться на товарища? Или потеряется перед ним? Или наоборот? Разумно ли это?
Самостоятельность, ответственность, стремление к поиску решений - все это может быть перечеркнуто добавлением дегтя.
Применение XP опасно, особенно если методологически и технологически необосновано.
Такие двойки требуют повышенного внимания менеджера, не случайно ХР ориентирован на небольшие команды.
А завтра? по три будут собираться? :)
Я не противник ХР, и даже наоборот, какая-то чувствуется выгода, но хочется ее выразить более конкретно и ускользает она от меня :)

[Case]

То есть отсутствовал момент мотивации, это раз (люди ходили друг к другу советоваться, но в паре работать не хотели); и наличествовал разный уровень подготовки - один участник был уже немного подготовлен, и поэтому априори вел себя как лидер, создавая асимметрию.

Это я, наверное, к тому, что процесс парного тестирования требует весьма неслабой подготовки и постоянной поддержки.

Вы описываете типичные проблемы, которые успешно решаются по ХР.
Любая парная работа это сложно - но реализуемо. Адепты ХР (к которым я не принадлежу) подробно описывают в чём выгоды от парной работы.

[Case]

Кстати, статью опубликовал СитФорум: http://citforum.ru/SE/testing/tandem/

PS
Это я хвастаюсь

[ZLZ]

Отличная статья :)

И очень вовремя, у нас как раз новичек приступил к работе, так что непременно ОПРОБУЮ этот подход.
А пока можно еще выделить плюсы такого подхода:
1/ у нас новенький на испытательном сроке, т.е. при парной работе есть дополнительная возможность оценить качества нового тестировщика, его способ мышления и то, как он решает поставленные задачи
2/ когда новенький начинает знакомиться с проектом, у него по любому возникают вопросы, и он либо задает их (старшему тестировщику приходится отвлекаться от своих задач), либо пытается разобраться сам (при этом ощутимы потери времени), описанный в статье подход обещает исправить это :).

Вобщем, статья предлагает замечательное решение в моем случае. Не думаю, что парное тестирование снизит самостоятельность, ответственность и стремление найти решение :), это зависит от участников, и поставленной задачи. Я собираюсь применить этот подход на начальном этапе, а потом тестирование пойдет по стандартной схеме. Но этап ознакомления и конкретизации задач обычно занимает много времени, и эта ситуация требовала разрешения :).

[Viktor]

Да перестаньте вы :),
Что у нас происходит :)?

Если один уч учит неуча, так это также далеко от ХР как и от нормальной работы.
По службе приходится этим заниматься, так хуже нет таких моментов.
Пусть лучше шеф за плечо встанет - тут такое ХР начнется, не остановишь :).

Вот здесь немного и не понятно: в статье "парное тестирование" - тестирование с участием двух профессионалов или один все-таки не дотягивает?
Про "первый раз" все понятно, да по другому и не научить (не ознакомить), а в заключении (статьи) опять какие-то новички :) - рекомендую переработать :) и про эффекты поподробнее написать, новичков не интересно вводить в дело, пусть им Илона на ночь шепчет :).

Case, расскажите лучше, как создать сбалансированную пару (как у Вас это получается).

[Case]

Вот здесь немного и не понятно: в статье "парное тестирование" - тестирование с участием двух профессионалов или один все-таки не дотягивает?
Про "первый раз" все понятно, да по другому и не научить (не ознакомить), а в заключении (статьи) опять какие-то новички :) - рекомендую переработать :) и про эффекты поподробнее написать, новичков не интересно вводить в дело, пусть им Илона на ночь шепчет :).

Подход работает и там и там - и для новых игроков (кстати новичёк - он не "лопух", куда вы его, по-моему, записывате - он просто новичёк в нашей команде) и для тех, кто уже работал.

Новичков не интересно вводить в дело? Угу, мои соболезнования тем, кого вы берёте на работу.

[Viktor]

Подход работает и там и там - и для новых игроков (кстати новичёк - он не "лопух", куда вы его, по-моему, записывате - он просто новичёк в нашей команде) и для тех, кто уже работал.

Новичков не интересно вводить в дело? Угу, мои соболезнования тем, кого вы берёте на работу.

Неправда, я ТАК даже не думал, вернее сначала не думал, а потом решил прояснить но слово лопух мне не нравится.
Не лопух - хорошо, я вот, например, сейчас крупный специалист (образно), а раньше 15 лет назад, кто?
Лопух? нет, неуч - да, непрофессионал - да. Лопух - сорная трава, сколько не возделывай - пользы никакой. Неуч - тот кто не учился (ну негде было).

А вот ответьте мне, каково мне - ведущему специалисту, не один год занимающимся своим делом, профессионалом, выбравшем свою специальность, заниматься делом которому я никогда не учился (обучение и ввод в курс) в ущерб своей работе и интересам? (Вопрос чисто риторический)
Моя практика показывает, паршивая (в смысле, болезнь такая, то есть, вполне приличная, но больная, хотя раньше шерсти давала ...) овца портит стадо, поэтому ее надо изолировать, вылечить (обучить :)), а дальше стриги вместе со всеми. Это нормальный (качественный) процесс (все болеют - надо ухаживать, никуда не деться от этого). Только придерживаясь качественного процесса можно получить качественный продукт. Некачественный процесс - некачественный продукт.
Мешать в кучу две цели (причем первая - обучение, не поддается контролю, анализу и оценке) - не приведет ли это не к синергетическому эффекту, а к отрицательному результату? Время опытного специалиста стоит в несколько раз дороже времени новичка. Я - "старший баран" (здесь шутка, не надо понимать буквально), а не "ветеринар".
Не случайно в аббревиатуре присутвует слово "Экстремальное" - времени нет учить, ресурсов нет, желания нет. Хочешь работать - подпрягайся и тащи.
Это мое понимание ХР, так я понял Вашу статью сначала, но по дискуссии появились какие-то вопросы, я их озвучил. Теперь вопросов еще больше.

Не интересно, Case, не в том смысле, что я тиран, бросаю в воду маленьких детей, а в том, что я давно поставил перед собой другие цели. И две из них совершенствовать информационные технологии и в них совершенствоваться. Технологии обучения меня абсолютно не привлекают, пусть простят меня потомки.
Кстати, никто не жаловался. Предлагаю вообще поговорить (в другой теме) кто и как растит и вводит в курс дела молодых, опытных, больных и сирых. :)

[Spy]

Предлагаю вообще поговорить (в другой теме) кто и как растит и вводит в курс дела молодых, опытных, больных и сирых. :)

Да, кстати, было б интересно.
У нас на форуме есть подобная тема:
Повышение уровня команды:
http://tester.com.ua...ct=ST&f=23&t=59

Но я думаю, там есть что дополнить!

[barancev]

Дискуссия сильно продвинулась в сторону обучения новичков тестированию.

А вот Джонатан Коул (Jonathan Kohl) в статье Pair Testing: How I Brought Developers into the Test Lab, опубликованной в январском номере SQA рассказывает о том, как он составлял пары, в которые входили тестировщик и программист. При этом, как он утверждает, в процессе совместной работы оба получают выгоду, которую могут использовать и после сеанса парного тестирования -- разработчик составляет более чёткое представление о способах использования пользователем разрабатываемой системы, а тестировщик лучше понимает принципы построения системы.

А на закуску -- комплект ссылочек по теме, заботливо собранных Джонатаном Коулом.