Идея для парного тестирования

      Уже некоторое время ношусь с идеей для парного тестирования, но пока нет возможности опробовать ее на практике. Делюсь - может кому пригодится.
      Сразу уточним: под парным тестированием в данном случае имеется в виду не то тестирование, когда двое сидят за одним компьютером и один тестирует, а другой смотрит.
Тогда о чем это мы? А вот о чем:
    
      Есть задача: быстро провести над ПО ряд заранее спланированных тестов. 

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

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

      Что выбрать зависит от приоритетов. И в зависимости от выбора мы выигрываем и проигрываем в следующем:

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

      Исследование дефекта и занесение отчета о нем в баг-трекер может занять пять минут, а может и двадцать – зависит от дефекта. Если у вас дефекты трудноуловимы и вы нашли в день, скажем шесть штук, то 6*20 = 2 часа выпало из тестирования по плану.

      Кто из тестировщиков не испытал это на себе? Когда мучительно продираешься сквозь дебри свежего билда, аки первопроходец сквозь джунгли. На каждом шагу - то лиана, то удав, то коварное тропическое насекомое. А можно на тигра наткнуться.  Или на слона. И каждый раз, когда видишь подозрительные следы, все внутри рвется вперед - исследовать, описать, захватить! Но захватив в плен врага, потом долго вспоминаешь, что там было до начала погони? На каком тесте я остановилась и что делала? В результате процесс движения по плану напоминает езду по ухабистой дороге, когда то и дело съезжаешь в канаву. И в конце дня обнаруживаешь, что хоть весь день едва ли дым из ушей не шел, но в результате - половина тестов не выполнена.

      Если перед нами стоит задача быстро прогнать набор тестов, то разумно при обнаружении бага делать себе пометки, но продолжать тестировать по плану. А к исследованию дефектов перейти после прогона всех тестов. Но во-первых, для тестировщика это морально травмирующее решение - знать о баге и не сообщить о нем немедленно, а во-вторых - это риск, ведь проблема может оказаться серьезной, а мы не доложим о ней вовремя.

      Как все тесты выполнить, и все дефекты исследовать, и сделать это быстрее, чем обычно?

Решение: распараллелить прогон тестов и исследование дефектов.

Как это сделать:

      Команда из двух тестировщиков, каждый за своим компьютером. Первый тестировщик начинает выполнять тесты по плану. И тестирует до тех пор, пока не будет обнаружен дефект. В этот момент подзывается напарник, которому показывают замеченные симптомы. Напарник подхватывает дефект, исследует и подписывает в баг-трекер. Первый тестировщик после передачи дефекта продолжает методично двигаться по плану.  И так до конца списка тестов.

Графически временные затраты можно представить так:

 

Последовательный вариант:

Параллельный вариант:

Из графиков видно, что мы можем немного проиграть в трудозатратах (суммарные человеко-часы двоих тестировщиков), но получаем выигрыш в скорости.  Мы сможем раньше закончить тестирование по плану, владея при этом полной информацией по обнаруженным багам. Во всяком случае более полной, чем в последовательном режиме работы.

Плюсы и минусы параллельного подхода:
+ прогон запланированных тестов будет завершен раньше (чем в последовательном режиме);
+ найденные  дефекты будут сразу же исследованы и подписаны, не надо ждать окончания тестирования по плану;
- нужно два тестировщика, вместо одного;
- второй тестировщик простаивает в периоды между дефектами (на графике это серые зоны);
- есть риск того, что второй почувствует себя на вторых ролях;
- есть риск того, что первому будет скучно;
-  заметность (visibility) работы второго тестировщика в баг-трекере растет, а у первого нет.

Можно ли как-то нивелировать минусы? Давайте посмотрим:

Минус	Что делать тест тим лиду
Нужно два тестировщика, вместо одного.	Этот аспект обойти нельзя. Если вы - единственный тестировщик в проекте или все остальные заняты неотложными задачами, то данная тактика для вас неприменима. В этом случае придется работать в последовательном режиме.
Второй тестировщик простаивает в периоды между дефектами.	Нужно дать задание на периоды простоя. Например: 1) Поручить второму прогон тестов с другого конца списка. Т.е. пока первый прогоняет тесты для функции “А”, второй начинает тестировать функцию “Я”. Как только один  из них находит дефект, тестировщик №2 бросает прогон тестов и приступает к исследованию дефекта. 2) С другой стороны, дополнительная ветка задач увеличивает время переключения между ними. Трудно сосредоточиться, когда вы то и дело дергаетесь то на одно, то на другое.  Так что в “серых” зонах можно устраивать классическое парное тестирование: один тестирует, другой смотрит на экран первого. 3) Придумать еще что-нибудь полезное.
Есть риск того, что Ловец Багов почувствует себя на вторых ролях.	●        Вести разъяснительную работу. Неустанно объяснять как сильно и почему нужна и важна работа каждого из пары. Можно делать это громко и во всеуслышание. ●        Поднять престиж этих ролей. Дать ролям гордые названия, сделать переходящие знаки отличия для каждой роли. ●        Менять местами тестировщиков. В этом билде Петя прогоняет тесты, а Вася ловит дефекты.  А в следующей сборке - наоборот.
Есть риск того, что Планопроходцу будет скучно.	●        Дать эту роль человеку, способному не скучать за такой работой. ●        Менять местами тестировщиков. ●        Замотивировать.
Заметность (visibility) работы второго тестировщика в баг-трекере растет, а у первого нет.	Вообще-то, если в компании и в проекте все в порядке, то это не должно не должно никого волновать. Вы, как руководитель группы, прекрасно знаете кто какой вклад делает в общее дело. И это уже ваша задача - обеспечить заметность работы ваших ребят начальству. Но если так случилось, что количество багов важно, можно: ●        менять тестировщиков местами; ●        вносить эти дефекты “на счет” обоих напарников.

   
      Свои мысли по поводу этой идеи можно бестрепетно излагать в комментариях :).