Процессы в каждой команде разные, но в общем виде воркфлоу разработки такой:
- QA kick-off
- реализация
- код-ревью
- QA demo
- blitz-тестирование
- staging/продакшн
QA Kick-off
Разработчик в паре с QE или с другим разработчиком, или и с тем и с другим сразу, запираются в комнате и брейнштормят на тему что может пойти не так при реализации фичи и про что нужно не забыть в процессе разработки. Составляется чеклист проверок, которые нужно будет сделать после реализации. Этот список заносится в специальное поле Test Notes в Jira. Здесь же можно обсудить, какие из проверок можно автоматизировать и на каком уровне это лучше сделать.
Реализация, код-ревью
Тут всё как обычно - разработчик пишет код, юнит-тесты, интеграционные тесты, UI-тесты. В некоторых командах % покрытия форсится в пул-реквестах, но в целом, все понимают, что покрытие само по себе ни о чём не говорит. На пул-реквест запускаются все существующие тесты.
В Confluence, например, проверяется так же интеграция с критически важными плагинами, живущими в отдельных репах. Подтягивается их код, они собираются, устанавливаются в Confluence, собранный в PR-е, и запускаются их интеграционные тесты. Суммарно получается от 10 до 20 разных сборок.
QA Demo
Эта практика только условно стоит после код-ревью. Она может проводится как до, так и параллельно с ним. Чаще всего параллельно. QE или разработчик в паре с автором изменений проводит сессию тестирования фичи. Задача этой сессии не перепроверить то что было в Test Notes (это на совести автора), а пощупать фичу вживую и найти новые тест-кейсы. Обычно после реализации и интеграции в существующий продукт, всплывают разные пользовательские сценарии, о которых не подумали во время kick-off - всего не предусмотришь.
Blitz
Если фича объёмная, то вся команда собирается на короткую сессию тестирования. Обычно это 15-30 минут. Blitz может быть тематическим - кроссбраузерность, тестирование безопасности, нагрузочное, UX-тестирование. А может быть просто исследовательским. Задача этой практики - посмотреть на фичу как можно большим количеством глаз.
Staging/продакшн
Из мастера периодически собираются релизы и выкатавыются сначала внутри, а затем пользователям. Фичи обычно релизятся за фича-флагами. Если внутри проблем не заметили, можно начинать включать фичу пользователям. Это сильно ускоряет процесс когда всё идёт хорошо. Если находятся какие-то проблемы, фичу сначала отключают через флаг, а затем откатывают либо чинят.
comments powered by Disqus