Парное тестирование

Если вы ищете «тестирование всех пар» или «попарное тестирование» (pairwise testing), то есть одну из техник тест-дизайна, тогда вам сюда.

А здесь речь пойдёт о нетривиальной методике тестирования, когда формируется пара сотрудников ИТ-компании, которые садятся за один стол и проводят сеанс совместного тестирования, или тестовую сессию.

• Суть методики
• Главное: коллаборация
• Зачем и когда проводится
• Характеристики
• Кого подсаживают за стол к тестировщику
• Скиллы
• Плюсы и минусы
• Процессы
  • Подготовка сессии
  • Проведение
  • Итоги
• Сложности
• Лучшие практики

Описание

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

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

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

Таким методом можно достаточно эффективно тестить сложный софт, экономя время команды и время обоих сотрудников.

Коллаборация

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

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

Итак, двое сотрудников садятся за рабочий ноутбук и рассматривают тестовые сценарии, делятся своими идеями и наблюдениями.

Парное тестирование чаще довольно-таки неформальный, спонтанный процесс (что не мешает создавать заметки и какую-то промежуточную документацию). 

Парное тестирование известно также как бадди-тестинг, «тестирование с другом», то есть с коллегой. Известно, что такой подход улучшает культуру сотрудничества в компании, укрепляя связи внутри департамента, и между департаментами.

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

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

В чем важность парного тестирования 

Любой проектной команде и вообще любой ИТ-компании нужна рабочая среда, в которой поощряется сотрудничество. Это помогает разрушить незримые барьеры между сотрудниками, подкорректировать стандартную standalone-модель работы, и поощряет стейкхолдеров, то есть всех заинтересованных в продукте — разработчиков, тестировщиков, продакт-менеджеров и маркетологов — смотреть друг на друга не как «еще один сотрудник», а как на ценного коллегу, который дополняет, помогает, советует.

Итак, парное тестирование убирает невидимые барьеры, и этим помогает улучшить качество софта и создать более продуктивную атмосферу в департаменте/компании.

Например, в QA-департамент компании, работающей в сфере телекоммуникаций, поступила на тестирование новая версия продукта; департамент, как и вся компания, работает по Agile, стало быть ориентируется в первую очередь на требования клиентов; зная, как важен в Agile дух сотрудничества в команде, проджект-менеджер выдвигает идею включить в рабочие процессы парное тестирование; QA-лид подбирает тестировщика и разработчика и формирует из них пару. Тестировщик управляет мышью и клавиатурой, пишет и выполняет тесты. Разработчик надзирает и руководит процессом, задает вопросы, дает подсказки, предлагает идеи по дизайну, и фиксирует текущие результаты сессии. 

Доказано, что подобный «коллаб» позволяет малыми усилиями улучшить юзабельность продукта, функциональность и дизайн. 

Ситуации, когда нужно парное тестирование

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

• Оценка текущих проблем с проектом, с разных точек зрения, от участников разных команд
• Улучшение корпоративной культуры в командах, то есть повышение квалификации персонала с точки зрения софт-скиллов
• Экспресс-валидация требований к продукту при нехватке времени
• Быстрый фидбек профессионалов в узкой сфере, не являющихся частью команды разработки или QA

Характеристики парного тестирования

В целом, разработчики и тестировщики работают достаточно изолированно. Парные сессии способствуют обмену знаниями и лучшему взаимопониманию между участниками QA и dev-команд. 

• Создание «быстрых» тест-кейсов.
• Методика экономная по времени: двое человек работают быстрее вместе, чем каждый по отдельности.
• Неплохой способ быстро обучать новичков на их стандартных задачах. 
• Улучшается сотрудничество в мультифункциональных командах
• От простых задач — к сложным.
• Активный обмен идеями и наблюдениями, общий опыт преодоления проблем — улучшает корпоративную культуру в ИТ-компании

Какие могут быть пары

В Agile проектах могут быть самые разные участники таких пар, например:

• Разработчик + тестировщик
• Тестировщик + тестировщик
• Тестировщик + продакт-менеджер
• Тестировщик + UI/UX-дизайнер

Разумеется, тестировщик является неотъемлемым участником пары, которого не получится заменить никаким другим сотрудником. 

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

Когда тестировщик работает в паре с другим тестировщиком, их опыт «умножается, а не суммируется».

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

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

Скиллы

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

Коротко скиллы:

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

Преимущества парного тестирования

Более подробно о преимуществах методики:

1. Учит людей из разных команд сотрудничать и вносить свой посильный вклад. Экспресс-обмен знаниями между командами и отдельными людьми позволяет «взглянуть на проект с высоты», и распространить знания о состоянии проекта рядовым его участникам.
2. Позволяет повысить качество процесса тестирования, поскольку один тестировщик легко может пропустить какой-то критический баг, особенно на начальных стадиях проекта.
3. Тестировщики-джуны работают с человеком из другого домена, с совсем другим опытом. У загруженных работой джунов часто «замыливается глаз», и они могут не замечать очевидных ошибок. 
4. Также сеанс работы в паре помогает получить фидбек по качеству своей работы не от непосредственного руководителя (что происходит каждый день и не всегда бывает комфортно), а от человека из другого отдела (от которого тестировщик не зависит).
5. Когда профессионалы из разных доменов, разных команд и ролей работают вместе на временной основе, они делятся своим уникальным критическим взглядом на разрабатываемый продукт. Это улучшает корпоративную культуру, прокачивает хард-скиллы тестировщика в ускоренном режиме, создает более приятную и легкую атмосферу.
6. Более качественные баг-репорты, на которые разработчики реагируют более внимательно и ответственно. Баги анализируются с технической точки зрения и с точки зрения клиента.
7. Методика помогает построить эффективную высокопродуктивную команду, с укорененной привычкой сотрудников делиться знаниями и легко принимать на себя ответственность. 

Недостатки парного тестирования

• Нежелательно имплементировать, если нет уверенности в результате, в частности: 
• Если с коллаборацией не сложилось, вряд ли можно будет положиться на результаты; ведь парное тестирование — это о коммуникации и о коллаборации.
• Если будут слишком простые «быстрые» тест-кейсы, выполнение их в паре вряд ли будет эффективнее чем по отдельности; один человек прекрасно справится с этой задачей и нет необходимости загружать второго. 

Процессы

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

Смок-тесты — частый случай парного тестирования. Приведем алгоритм действий проджект-менеджера/лида.

• Во первых, выберите «правильных людей которые сделают все правильно». Важно подобрать пару из двух людей, которым комфортно общаться. Они должны быть между собой более-менее знакомы, знать стиль работы друг друга, и легко общаться.
• Поставьте им цели, но в достаточно широких рамках, особенно если речь идет о «пробной» сессии. Также обрисуйте некую общую стратегию действий или план. Например, пара будет тестировать новую функцию, затрагивающую многие компоненты в приложении; в примерном плане можно указать ресурсы, тестируемые компоненты, а также ожидаемые результаты сессии.
• «Дуэт» нужно выделить рабочее место в офисе, достаточно комфортное для обоих, на протяжении по крайней мере часа-двух.
• Перед началом опишите роли каждого и сообщите участникам, кто будет ведущим и ведомым (как у летчиков). Один сотрудник мягко управляет процессом и дает другому замечания/указания/предложения/фидбек. При этом нет императивности: ведомый может возражать, оспаривать, предлагать вариант лучше.
• Опишите участникам процесс регистрации замеченных багов и предложений по совершенствованию продукта. 
• В конце создается более или менее формальный «протокол» проведенной сессии. Пара создает репорт с замечаниями о проблемах и  фиксирует свои предложения.

Моменты при подготовке тестовой сессии

Несмотря на общую неформальность exploratory testing и парного тестирования как одного из его подвидов, хорошей Agile-практикой является написание некой «ЕТ-хартии» для тестовой сессии, то есть примерного плана действий. Желательно более-менее детально описать в плане цели и процессы. 

• Цели
• Область тестирования (scope) и длительность
• Что будет тестироваться: какие компоненты и какая функциональность
• Какие ресурсы будут выделены
• Какие сложности возможны, и как они будут преодолены
• Целевые результаты тестирования

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

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

Опишите конечные цели, чтобы от тестирования была получена реальная ценность.

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

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

Приступаем к сессии

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

• Оба участника должны сотрудничать и выкладываться. 
• Должны понимать область тестирования
• Должны знать, что НЕ нужно тестировать, чтобы не тратить время на что-то второстепенное
• Нужно убедиться, что участники сессии помнят стандартный user flow тестируемой системы и ее наиболее часто используемые функции
• Стимулируйте уважение к точке зрения второго участника пары и старайтесь стимулировать креативность

Завершение тестовой сессии

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

• Что пошло хорошо, а что не очень, и где нужны улучшения
• Целевые результаты — валидированы
• Возможно, по результатам нужны будут изменения/корректировки в существующем тест-плане и в тест-кейсах, и в другой тестовой документации

Сложности

Возможные челленджи:

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

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

• Репорты и контроль дефектов. 

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

• Частая ошибка — «залипание» участников пары в незначительных вещах.

Тестировщик должен четко понимать конечные цели сессии и ожидаемые результаты, не отклоняться от запланированных целей и не терять время на что-то несущественное. 

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

Лучшие практики

В этой сфере, на опыте сессий, сложились стандарты и лучшие практики.

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

***