Жизнь без тестировщиков (часть 2)

Процессы в каждой команде разные, но в общем виде воркфлоу разработки такой:

  • 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