Регрессионное тестирование: что это и как не гонять всё подряд

Регресс — самая объёмная и самая скучная часть работы, и именно поэтому её чаще всего делают неправильно: прогоняют всё подряд, устают и всё равно пропускают важное.

Что такое регрессионное тестирование

Регрессионное тестирование отвечает на один вопрос: не сломалось ли то, что раньше работало. Не «работает ли новая функция» — это обычная проверка, — а именно «не задело ли соседнее».

Причина существования проста: код связан сильнее, чем кажется. Правка в расчёте скидки задевает корзину, корзина — оформление заказа, оформление — письма и отчёты. Разработчик не всегда знает обо всех связях, и никто не знает.

	Ретест	Регресс
Вопрос	Починили ли этот дефект	Не сломалось ли рядом
Объём	Один сценарий	Много сценариев
Когда	После каждого исправления	Перед релизом или регулярно
Кто чаще делает	Тестировщик руками	Автотесты, если они есть

Главная ошибка: прогонять всё

Первая реакция на слово «регресс» — взять весь набор кейсов и пройти его целиком. На маленьком продукте это работает. Дальше набор растёт, прогон занимает три дня, а релизы выходят каждую неделю — и регресс превращается в ритуал, который делают «на скорость» и без внимания.

Правильный подход — выбирать. Регресс не обязан быть полным, он обязан покрывать риск.

Полный прогон, сделанный формально, находит меньше, чем половина прогона, сделанная осмысленно.

Как выбрать, что проверять

1. Посмотрите, что менялось. Список задач в сборке — отправная точка. Не список функций продукта, а именно изменения.
2. Определите зону влияния. Спросите разработчика, что он трогал: часто ответ «поменял общий компонент кнопки» меняет весь план.
3. Добавьте критичные сценарии всегда. Регистрация, вход, оплата, оформление заказа — они идут в каждый регресс независимо от изменений.
4. Добавьте места с историей. Если этот модуль ломался три раза за квартал, он идёт в набор.
5. Проверьте интеграции. Всё, что общается с внешними сервисами, ломается тише всего.

Что делать, когда времени нет совсем

Ситуация обычная: релиз завтра, регресс идёт два дня. Работающий порядок — по убыванию цены ошибки.

• Деньги. Оплата, списания, возвраты, расчёт сумм.
• Доступ. Вход, выход, права ролей, восстановление пароля.
• Потеря данных. Сохранение форм, черновики, корзина.
• Основной путь. Сценарий, ради которого продукт существует, от начала до конца.
• Всё остальное — если останется время.

И обязательно сообщите команде, что осталось непроверенным. Сокращённый регресс — нормальное решение, скрытый сокращённый регресс — источник сюрпризов.

Когда автоматизировать

Регресс — первый кандидат на автоматизацию, потому что повторяется без изменений. Но переводить всё подряд в автотесты не стоит: неустойчивый тест, который падает через раз, вредит больше, чем помогает — команда привыкает игнорировать красное.

Признаки того, что сценарий пора автоматизировать: он выполняется каждый релиз, у него стабильный результат, он не завязан на визуальную оценку и его поломка означает серьёзную проблему. Сценарии, которые меняются каждый спринт, дешевле проходить руками.

Кто и когда проводит регресс

Организация прогона зависит от того, как часто выходят релизы, и здесь есть два рабочих подхода.

Подход	Как устроен	Кому подходит
Перед релизом	Отдельный этап на день-два, участвует вся команда тестирования	Релизы раз в две недели и реже
Непрерывно	Автотесты гоняются на каждой сборке, руками проверяется только затронутое	Ежедневные выкаты

Второй подход требует зрелой автоматизации, но он же единственный, который выдерживает частые релизы. Первый проще, но у него есть неприятное свойство: чем ближе дата, тем сильнее соблазн прогнать формально.

Отдельная роль — регресс после исправления инцидента. Когда чинили на горячую, проверить нужно не только сам фикс, но и то, что спешка ничего не задела. Такие прогоны пропускают чаще всего именно потому, что все уже выдохнули.

Как поддерживать набор в форме

Набор регресса — живой документ. Если его не чистить, он растёт бесконечно и постепенно наполняется проверками функций, которых уже нет.

• После каждого серьёзного дефекта в проде добавляйте проверку, которая бы его поймала.
• Раз в квартал убирайте проверки функций, которые удалили или переделали.
• Отмечайте, какие проверки за полгода ни разу ничего не нашли, — кандидаты на удаление или переработку.
• Держите приоритеты внутри набора, чтобы сокращённый прогон собирался за минуту, а не пересобирался каждый раз заново.

Как оформлять сами проверки — в разборе чек-листов и тест-кейсов. Быстрая проверка перед регрессом — чек-лист smoke-теста.