Что такое регрессионное тестирование?
Регрессионное тестирование — повторная проверка уже работавшей функциональности после изменений в коде. Его цель — убедиться, что новая функция или исправление бага не сломали ничего из того, что раньше работало.
Необходимость возникает из связности кода: правка в расчёте скидки может неожиданно повлиять на формирование чека или отчётность. Чем крупнее система, тем менее очевидны такие связи, и тем важнее регулярно перепроверять старые сценарии.
Регрессию проводят перед каждым релизом, и именно она — главный кандидат на автоматизацию: набор проверок стабилен, повторяется постоянно и вручную занимает слишком много времени. В зрелых командах регрессионный набор запускается автоматически при каждой сборке.
Где применяется
Регрессию прогоняют перед каждым релизом, а в командах с частыми выкатками — при каждом изменении кода через конвейер CI. Набор собирают из проверок критичных сценариев: вход в систему, оформление и оплата заказа, ключевые расчёты, интеграции с внешними сервисами.
Со временем набор разрастается и начинает тормозить выпуск версий. Поэтому его регулярно пересматривают: убирают дублирующие проверки, разбивают на быстрый прогон для каждого изменения и полный — перед релизом, а самые долгие тесты запускают ночью.
Пример
Команда исправила расчёт скидки для новых клиентов. Проверка показала, что скидка считается верно — но регрессия обнаружила, что вместе с ней сломался расчёт для постоянных покупателей, которого исправление вообще не касалось.
Частые вопросы
Чем регрессионное тестирование отличается от ретеста?
Ретест проверяет, что конкретный дефект действительно исправлен. Регрессия проверяет, что это исправление не сломало ничего вокруг. Ретест точечный и короткий, регрессия охватывает работавшую ранее функциональность и обычно выполняется набором проверок.
Как часто нужно прогонять регрессию?
Минимум перед каждым релизом. Если проверки автоматизированы, их запускают при каждом изменении кода — это самый дешёвый способ ловить поломки сразу. Ручную регрессию из-за трудоёмкости обычно проводят по сокращённому набору и только на критичных сценариях.
Что делать, когда регрессия занимает слишком много времени?
Пересматривают набор: удаляют дублирующие и потерявшие смысл проверки, расставляют приоритеты по рискам, автоматизируют самое повторяемое. Помогает и разделение на уровни — быстрые проверки при каждом изменении, полный прогон реже, тяжёлые сценарии ночью.
Можно ли обойтись без регрессионного тестирования?
На разовом проекте, который больше не будут менять, — да. В живом продукте это самый частый источник неприятных сюрпризов: код связан сильнее, чем кажется, и правка в одном месте регулярно проявляется совсем в другом.