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