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