Формируете ли отдельные прогоны на регрессию
Что проверяют
Есть ли у вас управляемая регрессия: понятный набор, критерии отбора, расписание. И умеете ли вы держать время прогона в разумных рамках, потому что регресс растёт сам собой и однажды перестаёт помещаться в релизный цикл.
Как отвечать
Скажите, что прогоны разделены, и покажите устройство. Рабочее деление:
- смоук: критические пути, минуты, гоняется на каждую сборку;
- регресс по затронутым областям: отбирается по тому, что менялось, идёт на ветку релиза;
- полный прогон: весь набор, ночью или перед релизом.
Критерии попадания в регресс называйте явно: критичность функции для бизнеса, история дефектов (нашли баг, добавили проверку), зоны частых изменений, интеграции с внешними системами, деньги и права доступа.
Отдельно про поддержку набора, это и отличает опыт от теории. Дубли удаляются, часть проверок спускается на уровень API и юнит-тестов, нестабильные тесты уходят в карантин, а не перезапускаются до зелёного. Полезные метрики: время прогона, доля упавших не по вине продукта, найденные регрессии на релиз.
Где спотыкаются
Приносят круглые числа из шаблонов: «сократили время тестирования на тридцать процентов, дефектов стало меньше на сорок». Спросят, чем мерили, что было до, за какой период. Лучше говорить то, что можете защитить.
Называют регрессом прогон всех тест-кейсов подряд. Это как раз отсутствие отбора: набор раздувается, прогон не помещается в ночь, и команда начинает запускать его через раз.
Не разбирают падения, а перезапускают. После нескольких таких релизов красный отчёт перестают читать вовсе, и настоящая регрессия проезжает в прод ровно так же, как если бы тестов не было.