Что такое TestFest, или Как мы тестируем без отдельного QA
[Об авторе: Сергей Королев — управляющий директор в Railsware с более чем
В прошлой статье мы описали подход к Quality Assurance, который практикуем в компании. Как и обещал, в этой статье расскажу о том, как мы тестируем продукты без выделенных мануальных тестировщиков. Речь пойдет о TestFest — одной из важных составляющих процесса Quality Assurance в компании.
В процессе перехода от аутсорсинга к модели software consultancy мы постепенно ушли от необходимости иметь в команде отдельного человека для ручного тестирования. Эта функция перешла на команду продакт-менеджеров и инженеров, тем самым усилив их экспертизу и повысив уровень ответственности за создаваемые продукты.
Стоит отметить, что мы рассматриваем QA отдельно как функцию и как роль. В результате экспериментов мы смогли распределить функцию по всей команде. Набор подходов к разработке (описанный в предыдущей статье) помог оптимизировать процесс, и тем самым уменьшилось количество часов, необходимых для ручного тестирования. Это привело к сокращению роли мануального тестировщика, при том, что сама функция работает и сегодня.
Что такое TestFest
Мы стараемся, чтобы покрытие unit- и интеграционными тестами кода стремилось к 100%. Более того, функциональность каждой новой фичи проверяется повторно на TestFest.
TestFest — это сессия мануального тестирования фич до перехода в продакшн. Участники команды тестируют соседние фичи (те, которые не разрабатывали сами), тем самым получая доступ к более широкой картине функциональности продукта. Частота проведения сессии зависит от стадии разработки. В активной фазе TestFest-ом заканчивается каждая итерация (раз в 2 недели). На стадии более комплексных итераций или рефакторинга TestFest проводится реже.
Планирование
В зависимости от размера проекта, команды и фич, TestFest может занимать от нескольких часов до целого дня. Сессию необходимо планировать заранее, чтобы предотвратить накладки с другими активностями команды. TestFest не стоит проводить непосредственно перед релизом. В случае выявления багов, вам понадобится время для исправления наиболее критичных и тех, которые не могут ждать следующей итерации.
Scrum Master, Product Manager или Lead Engineer (в зависимости от структуры команды) отвечает за формирование списка чоров и фич для тестирования.
Составляя указанный список, ведущий утверждает с командой среду для тестирования:
- Девайсы для тестирования — десктоп, лэптоп, планшеты, смартфоны с разным разрешением экрана.
- Операционные системы — Macintosh, Windows, Linux, iOS, Android и т. п.
- Браузеры — Safari, Chrome, FireFox, Internet Explorer, Edge и т. п.
Ведущий процесса должен убедиться, что каждый участник TestFest получил свой уникальный набор «девайс-ОС-браузер».
Если у команды нет доступа ко всем девайсам или операционным системам, можно использовать эмуляторы. Например, мы часто пользуемся BrowserStack.com — инструмент разработан специально для тестирования, и может имитировать множество устройств и операционных систем.
Сессия
Главный результат TestFest — список выявленных багов. Мы предпочитаем работать с результатами в тот же день: если улучшения не терпят до следующей итерации, они сразу берутся в работу. Остальные проблемы обсуждаются, получают свой приоритет и добавляются в общий скоуп для последующего исправления и покрытия тестами.
В результате проведения сессии получаем лог такого формата:
Достаточно редко, но попадаются одновременно серьезные и срочные баги. В этих случаях запасной день между TestFest и релизом будет очень даже кстати. В такой ситуации мы рекомендуем запланировать еще один TestFest, особенно если один баг препятствует тестированию остальной функциональности продукта.
Почему это работает
Наша цель — качественный продукт. И, несмотря на приверженность к максимальной автоматизации, мы не отрицаем важность функции ручного тестирования в некоторых случаях. Возможность предсказать поведение конечного пользователя и предотвратить проблемы, с которым он может столкнуться, — очевидное преимущество ручной валидации.
Но, при комплексном подходе, альтернативы внедрения функции ручного QA существуют. Одну из них наша команда испробовала при переходе к модели software consultancy. Наши способы тестирования продуктов были трансформированы на ряду с остальными подходами. Как результат, мы смогли оптимизировать функцию QA, что привело к сокращению потребности в отдельном тестировщике. Сегодня Quality Assurance обеспечивается unit- и integration-тестами, парным программированием, кросс ревью кода, а также результатами TestFest сессий (больше деталей в предыдущей статье).
Среди основных преимуществ трансформации QA и применения TestFest-ов выделю следующие:
- У команды появился более широкий обзор всей функциональности продукта. Тестируя соседние фичи, каждый участник получает более полную картину того, как части взаимодействуют между собой и с целым.
- Так как функция тестирования теперь на инженерах, они изначально более ответственно относятся к написанию кода и покрытию его тестами. На этапе TestFest получаем код со значительно меньшим количеством багов.
- TestFest помогает быстрее выявлять проблемы в продукте, так как одновременно тестируются разные части функциональности продукта. При правильном планировании критические баги удается выявить и устранить за короткий промежуток времени.
Конечно, существуют специфические комплексные продукты, требующие индивидуального подхода к тестированию, и, возможно, в этих случаях отдельная роль Manual QA незаменима. Наша же модель была неоднократно проверена на практике, и подтвердила свою эффективность.
