Как устроен процесс регрессии?
Что проверяют
Понимаете ли вы регрессию как управляемый процесс с выбором объёма, а не как «прогоняем все тесты перед релизом». Почти всегда следом спрашивают, как вы решаете, что включить в регресс, если на полный прогон нет времени.
Как отвечать
Начните с определения: регрессионное тестирование проверяет, что изменения (фикс, новая фича, обновление библиотеки, смена конфигурации) не сломали то, что уже работало. Дальше опишите цикл:
- анализ изменений: смотрите, что затронул релиз, по задачам, диффу и разговору с разработчиком. Отсюда карта рисков и связанных модулей;
- выбор объёма: полный регресс, выборочный по затронутым областям или смоук критичных сценариев. Приоритет задают частота использования функции, цена ошибки и история дефектов;
- регрессионный набор: отдельный набор кейсов в TMS (TestIT, Qase, Allure TestOps и подобные), который пополняется после каждого найденного бага и чистится от устаревших проверок;
- прогон: стабильная часть автоматизирована и идёт в CI на каждый merge request или ночью, вручную остаются сложные и редко меняющиеся сценарии;
- анализ и отчёт: упавший тест не равен багу. Сначала отделяете дефект от флака и от проблемы окружения, потом заводите баг и даёте команде вывод о готовности релиза.
Хорошо звучит пример из вашей практики: сколько кейсов в регрессе, какая доля автоматизирована, сколько занимает прогон и как вы его сократили. Цифры берите свои, выдуманные на собеседовании быстро разваливаются на уточнениях.
Где спотыкаются
Путают регрессионное тестирование с повторным (re-test). Повторное проверяет, что конкретный баг исправлен, регрессионное проверяет всё вокруг, что это исправление могло задеть.
Говорят «регресс всегда полный». На частых релизах это нереально, и интервьюер ждёт критерии выбора: риски, затронутые модули, приоритет кейсов.
Не упоминают поддержку набора. Регресс без чистки разрастается до сотен дублирующих и устаревших кейсов, а нестабильные автотесты, которые все привыкли перезапускать, перестают что-либо ловить.