Авторы: Оля Фазулзянова, тестировщик Контур.Экстерна и Оля Изюрьева, тестировщик Контур.Биллинга и организатор курса тестировщиков.

Оригинальная публикация

Девушки рассказали о парном тестировании, о задачах, которые оно помогает решить, и привели пример неудачного использования практики.

В методологии XP есть практика — парное программирование. Во многих источниках написано о массе его преимуществ: высоком качестве кода, взаимозаменяемости разработчиков и т. д.

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

В Википедии нет термина «парное тестирование», но есть определение для парного программирования, которое можно взять за основу. Тогда, на наш взгляд, мы получаем следующее.

Парное тестирование — это техника, при которой тестирование одной функциональности производится парой людей за одним рабочим местом. Один тестировщик («ведущий») управляет компьютером, второй («штурман») непрерывно следит за работой первого. При этом на всем протяжении работы над задачей они обмениваются идеями и обсуждают их.

Любая практика — всего лишь инструмент. Мы не хотим забивать гвозди микроскопом, поэтому всегда отталкиваемся от задачи. Давайте рассмотрим те задачи, для которых релевантно использование практики «парное тестирование».

Задача: наставничество

В любой момент в команду может прийти новый человек. Ожидания команды от него — достаточно быстрое погружение в коллектив и в специфику проекта и, конечно, качественное выполнение своей работы. Чтобы ожидания стремительно превращались в реальность, во многих компаниях существует процесс наставничества. А вот что будет, если наставничество реализовать через парное тестирование?

Пример:

В проект пришел новый тестировщик, с опытом или нет — не важно. Вы, как наставник, садитесь с ним за ваш рабочий компьютер и начинаете выстраивать процесс следующим образом: в самом начале за вами закреплена ведущая роль, и первоочередная цель — познакомить новичка с процессами проекта и предметной областью. Знакомство может быть через рассказ, презентацию или сразу через совместное тестирование задач.

Начать можно с обсуждения сути задачи, поиска ответов на вопросы и проработки плана тестирования. Когда все готово для тестирования, вы берете клавиатуру и мышь и показываете, как тестировать, а новичок наблюдает. Никто не запрещает меняться ролями и рабочими местами на последующих задачах. Главное, не менять суть — совместное тестирование задач за одним рабочим местом до тех пор, пока вы не будете уверены в своем напарнике.

Профит:

• Новичок быстрее адаптируется в коллективе. У него есть точка входа — наставник, через которого можно познакомиться с остальной командой. Также у новичка сформируется представление о зоне ответственности коллег, ведь в ходе поиска ответов на вопросы вы сразу будете направлять его к нужным людям.
• Новичок быстрее разберется с новой предметной областью.
• Если новичок без опыта тестирования, то он узнает на практике о новых техниках тестирования и оценит их применимость.
• Происходит шаринг знаний: о процессах разработки, о техниках, об инструментах тестирования.
• У новичка взгляд не замылен, поэтому он может привнести новые нестандартные сценарии.
• Наставник быстрее определит уровень подготовленности нового человека. Это поможет своевременно скорректировать вектор развития, подбирая под него задачи.
• Тимлид тестирования и/или менеджер разработки не отвлекаются на адаптацию новичка. Новичок в надежных руках, и с качеством первых задач проблем точно не будет.

Мини-вывод:

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

Задача: повышение квалификации

Мы можем столкнуться с тем, что для успешного выполнения своей работы нам нужно обладать знаниями смежных специализаций: уметь составлять документацию, автоматизировать задачи и т. д. Как быстро и недорого нарастить компетенции? Обратиться к члену своей команды.

Пример:

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

Профит:

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

Мини-вывод:

Работа в паре позволяет получать знания в новой сфере быстро и эффективно, сразу закрепляя их на практике.

Задача: избавление от незаменимости (bus-factor)

Очень часто в командах есть люди — единственные носители определенных знаний. Зачастую таким человеком становится тестировщик, ведь он знает всё: пользовательские сценарии, как реализованы сервисы, что необходимо настроить на тестовой и многое другое. Но в жизни бывают ситуации, которые могут лишить проект источника знаний (увольнение, отпуск, больничный...). Следовательно, чтобы минимизировать последствия, можно подстраховаться и заранее расшарить знания из одной головы в несколько. Как? Через парное тестирование, конечно!

Пример:

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

Профит:

• Уменьшается давление ответственности, вам спокойно можно идти в отпуск, на стажировки и т. д.
• Работа в паре позволит сменить контекст и разбавить рутину узкоспециализированному тестировщику.
• Менеджер спокоен, ведь знаниями обладают несколько человек и с уходом одного работа не встанет.

Мини-вывод:

Если есть узкие специалисты, то парная практика для вас. Она повышает взаимозаменяемость и передачу актуальной информации.

Задача: получение обратной связи

Если команда тестирования состоит из нескольких человек, то применима практика обратной связи. Парное тестирование — подходящий инструмент для ОС.

Пример:

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

Профит:

• У вас или у вашего коллеги сложится представление о скиллах напарника.
• У вас или у вашего коллеги будет представление о векторе развития на основе обратной связи.
• Обратная связь о коллегах будет обоснованная, ведь она будет подкреплена примерами.

Мини-вывод:

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

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

Случай из жизни, или Не делай как мы

На одной из ретроспектив команды тестировщиков были выявлены следующие проблемы:

• неодинаковая работа (способ и время тестирования похожих задач сильно зависели от конкретного человека);
• слишком размытая обратная связь друг о друге (часто одной задачей занимался только один человек, и в конце полугодия о многих коллегах нечего написать, кроме как «Вася хорошо справляется со своей работой, он ответственный, отзывчивый и коммуникабельный»).

Сформулировав эти проблемы, мы поставили перед собой задачи:

1. Обменяться опытом и выявить лучшие способы и инструменты для тестирования схожих задач.
2. Создать условия для сбора более подробной обратной связи.

Договорились, что для их решения воспользуемся практикой парного тестирования.

Я и моя коллега вдвоем приступили к одной задаче тестирования.
Фронт работ был достаточно объемным, требовалось:

1. Разобраться в новой предметной области.
2. Проверить аналитику и найти в ней неучтенные сценарии.
3. Подготовить среду для тестирования.
4. Подготовить тестовые данные.
5. Составить тест-кейсы.
6. И протестировать в конце концов :).

Все это нужно было сделать с нуля.

Сев за один компьютер, мы начали читать аналитику. Договорились прочитывать один абзац или часть текста, а затем обсуждать возникшие вопросы и уже накидывать первые тест-кейсы. Поскольку аналитика была довольно слабо проработана и содержала в себе вперемешку бизнесовую и техническую часть, порой на обсуждение 10 строк текста уходило 15–20 минут. Кроме того, чтобы окончательно разобраться с каждым вопросом, требовались уточнения от аналитика, разработчика или специалиста техподдержки. Все эти сообщения и письма писались тоже в паре.

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

Столкнувшись со всем этим, мы решили притормозить и провести встречу, чтобы обсудить ход работы и успешность парного тестирования.

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

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

Строго говоря, поделиться знаниями получилось, но это были мелочи вроде:

• использования новых горячих клавиш,
• использования каких-то специфических фишек багтрекера,
• ...

Этими знаниями можно делиться и не прибегая к такой дорогой практике.

К концу встречи мы сделали для себя выводы:

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

2. Подбирайте задачи по тестированию так, чтобы практика была применима.
   Новая, сложная и объемная задача слабо подходит для парного тестирования:
   — сложно обучить кого-то;
   — не получается обменяться опытом;
   — трудно собрать обратную связь.

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

Существует множество разных практик. Какие из них применять в работе, зависит только от вас. Главное, не забывайте, зачем вы их применяете, и не используйте практики ради практик.

Обсудить в форуме