"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 за счет вынесения части проверок нового функционала в отдельный этап.
Итого
Большинство найденных проблем возникали не внутри самой фичи, а на пересечении нескольких систем. И именно там подход оказался наиболее полезным.
