Peer testing на основе Закона Линуса

«Given enough eyeballs, all bugs are shallow»

Вступление

Читая про Закон Линуса, нам понравилась идея о том, что при достаточном количестве независимых проверок большинство проблем становится быстро обнаруживаемым. Это натолкнуло нас на мысль адаптировать подобный подход в QA процессах с минимальными ресурсными затратами. Основная идея заключалась в том, чтобы перед стартом регресса версии, но после завершения работ разработки новых фичей (Фичефриза), новые фичи дополнительно проверялись другим тестировщиком, а не только ответственным за фичу QA.

Как мы решили это реализовать

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

Пример пайплайна:

• На старте разработки, фича “Бег” была закреплена за мной

• Изучаю требования, тестирую функциональность и составляю чек-листы

• Тут стадия активной разработки

• Версия уходит в фичефриз и формируется билд для плейтеста

• Приступают к работе GD, где они плейтестят и шатают баланс

• Определяются финальные даты Peer тестов

• Я передаю свою фичу коллеге QA, который на основе чек-листа, описанных рисков и опасных зон формирует собственный тестовый набор.
  Его задача — независимо перепроверить сценарии, наиболее подверженные регрессиям и межфункциональным конфликтам.

• После завершения формирования всех чек листов для Peer тестов формируется общий тестовый набор и отдел приступает к тестам за отведенное время

• Каждый QA повторно проверяет функциональность с упором на менее очевидные сценарии и зоны риска.

• Формируются артефакты тестирования. Баги в трекер, отчет в чат

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

Прим. Неочевидным бонусом является возможность подчистить за новым\неопытным специалистом, минимизируя риск отказа по этому фактору

«Безумие — это точное повторение одного и того же действия раз за разом в надежде на изменение «

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

Ограничения подхода

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

Высокая нагрузка на переключение контекста требует более качественного ведения документации и передачи контекста между QA.

На небольших проектах с коротким регрессом отдельный этап Peer тестов зачастую просто не оправдывает затраты времени.

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

Плюсы подхода

• Снижаются риски замыленного взгляда со стороны ответственного QA

• Повышается вероятность обнаружения регрессий, интеграционных и пограничных проблем

• Проверка начинает охватывать менее очевидные зоны риска, связанные с легаси и параллельной разработкой

• Знания о функциональности распределяются между несколькими QA

• В краткосрочной перспективе снижается bus factor

• Появляется дополнительная проверка качества тестовой документации

• Подход относительно дешево встраивается в существующие процессы

Минусы подхода

• Может увеличивать общее время разработки

• Возможны дублирование проверок и размывание ответственности

• Эффективность сильно зависит от качества документации и вовлеченности QA

• При недостатке времени проверки могут становиться поверхностными

• Требует постоянной актуализации тестовой документации

• Может создавать ложное ощущение полноты покрытия

  Какие проблемы этот подход ловит лучше всего

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

• конфликты между фичами

• скрытые зависимости

• повреждение состояний

• Проблемы конфигов

• пограничные сценарии

Когда подход не нужен

Как правило, на небольших проектах с коротким циклом релизов и хорошо изолированными фичами дополнительный этап проверки не оправдывает затраты времени.

А почему у нас это применимо

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

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

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

Пример типичного кейса у нас:

Во время разработки фичи “Повар” вся функциональность проверялась в изолированном окружении и успешно проходила тестирование.

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

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

Второй QA с большей вероятностью проверяет нестандартные сценарии вне уже сформированных ожиданий о поведении системы.

Про цифры

В среднем на версию у нас фиксируется около 70 дефектов.

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

Из них:

• около 10 обнаруживается во время альфа- и бета-тестирования

• около 15 находится во время дотестов задач, не успевших пройти полноценную проверку в активной стадии разработки

• еще от 1 до 4 дефектов стабильно обнаруживаются во время Peer тестов

Несмотря на сравнительно небольшое количество найденных дефектов, в среднем речь идет примерно о 10% всех проблем, найденных после фичефриза, именно такие проблемы чаще всего имеют высокий шанс дойти до релиза

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

Итого

Большинство найденных проблем возникали не внутри самой фичи, а на пересечении нескольких систем. И именно там подход оказался наиболее полезным.