Регрессионное тестирование: что это и зачем
Любой разработчик знает это чувство: исправил одну ошибку — и следом всплыли три новые, в местах, которые никто не трогал. Продукт — не набор изолированных кнопок, а связанная система: правка в оплате может уронить корзину, обновление библиотеки — сломать авторизацию. Регрессионное тестирование существует ровно для того, чтобы ловить такие сюрпризы до пользователя, а не после гневного отзыва в сторе.
Продукты, которые мы ведём в заказной разработке, живут годами: их дорабатывают, интегрируют с новыми системами, обновляют под требования сторов. На каждом изменении есть риск сломать то, что уже работало. Регресс — страховка от этого: скучная строка в смете ровно до первого случая, когда обновление уронило продажи на сутки.
Если совсем коротко. Регрессионное тестирование — это повторная проверка уже работавших функций после любых изменений в коде (новая фича, исправление бага, обновление зависимостей), чтобы убедиться, что ничего не сломалось.
«Регрессия» — это и есть ситуация, когда ранее исправная функциональность перестала работать. Регресс не путать с ретестом (перепроверкой конкретного исправленного бага), smoke (беглой проверкой, что сборка вообще живая) и sanity (проверкой одной узкой области).
Регресс бывает полным, частичным и выборочным; устойчивые повторяемые сценарии автоматизируют и гоняют на каждое изменение, остальное проверяют руками.
Что такое регрессия и почему «починили одно — сломалось другое»
Начать стоит с самого слова. Регрессия в тестировании — это возврат к худшему состоянию: функция, которая раньше работала, после изменений сломалась. Регрессионное тестирование — процесс поиска таких поломок.
Откуда они берутся, если менялся совсем другой участок? Причина в связанности кода. Современный продукт держится на общих модулях, библиотеках и данных: один и тот же код обслуживает несколько функций, компоненты вызывают друг друга, а внешние зависимости обновляются целиком.
Правишь расчёт скидки — задеваешь общий модуль корзины, которым пользуется ещё и оформление заказа. Обновляешь версию фреймворка ради одной фичи — меняется поведение везде, где он используется. Побочные эффекты — норма, и предугадать их в голове на большом продукте невозможно.
Отсюда правило: любое изменение потенциально ломает что-то ещё, поэтому после изменений проверяют не только новое, но и старое. Именно это «проверяют старое» и есть регресс.
Регресс, ретест, smoke и sanity: не путать
Четыре термина, которые постоянно смешивают, — а спрашивают в интервью и в жизни именно про разницу. Разложим.
| Вид | Что проверяет | Когда запускают |
|---|---|---|
| Регресс | Что старые функции не сломались после изменений | После любых доработок, регулярно |
| Ретест (повторное) | Что конкретный найденный баг действительно исправлен | После фикса этого бага |
| Smoke | Что сборка в принципе рабочая, ключевые функции живы | Сразу после новой сборки, до подробных тестов |
| Sanity | Что конкретная узкая область работает после точечной правки | После небольшого изменения в одной функции |
Разница по сути. Ретест отвечает на вопрос «починили ли мы этот баг», регресс — «не сломали ли мы при этом что-то ещё»; их часто делают в паре, но это разные проверки.
Smoke — беглый обход «горит или не горит»: если критические сценарии падают, дальше тестировать бессмысленно, сборку возвращают. Sanity — узкая и глубокая проверка одной области, когда полный регресс избыточен. Smoke широкий и поверхностный, sanity узкий и подробный.
На практике smoke обычно оказывается подмножеством регресса: самые критичные регрессные сценарии выделяют в smoke-набор и гоняют чаще всего.
Виды регрессионного тестирования
Регресс не обязан каждый раз перепроверять весь продукт — это дорого и часто избыточно. В зависимости от объёма выделяют три вида.
Полный (full). Прогоняют весь набор регрессных тестов — всё, что может быть затронуто. Дорого и долго, поэтому применяют перед крупными релизами, после серьёзной переработки или обновления ключевых зависимостей, когда затронуть могло что угодно.
Частичный (partial, region-based). Проверяют изменённую область плюс связанные с ней функции. Компромисс между надёжностью и скоростью: не гоняем весь продукт, но покрываем зону риска вокруг правки. Самый частый режим в обычной работе.
Выборочный (selective). Прогоняют только те тесты, которых напрямую касается изменение, — по карте зависимостей между кодом и тест-кейсами. Быстро, но требует зрелого понимания того, что на что влияет; ошибка в выборе зоны означает пропущенную регрессию.
| Вид регресса | Объём | Когда применять | Цена |
|---|---|---|---|
| Полный | Весь регрессный набор | Перед релизом, после крупных изменений | Высокая |
| Частичный | Зона изменения + связанное | Регулярные доработки | Средняя |
| Выборочный | Только затронутые тесты | Точечные правки при зрелой карте зависимостей | Низкая |
Что перетестировать: как выбирают объём
Полный регресс на каждое изменение никто не гоняет — на живом продукте это парализует разработку. Значит, каждый раз решают, что именно проверять. Разумный отбор строится на трёх факторах.
- Зона изменения. Что правили и с чем этот код связан. Общий модуль корзины тянет за собой всё, что от него зависит; изолированная правка текста на одном экране — почти ничего.
- Риск и критичность. Функции, поломка которых бьёт по деньгам и репутации (оплата, авторизация, оформление заказа), проверяют всегда, даже если правка их вроде бы не касалась. Цена пропущенной регрессии здесь несопоставима со стоимостью прогона.
- Частота использования. То, чем пользуются каждый день, важнее редких сценариев из глубины настроек.
Из этих факторов собирают регрессный набор — и его нужно поддерживать. Здоровый набор регулярно чистят: устаревшие кейсы удаляют, под новую функциональность добавляют новые. Разбухший набор, где половина тестов проверяет давно удалённые фичи, — распространённая болезнь: он долго гоняется и создаёт иллюзию покрытия там, где его уже нет.
Ручной или автоматизированный регресс: когда что
Главный практический вопрос. Регресс — это повторяющаяся из релиза в релиз проверка одних и тех же сценариев, и по природе своей он идеально ложится на автоматизацию: машине не надоедает в сотый раз проверять оформление заказа, и делает она это за минуты. Но автоматизировать всё подряд — ошибка, которая обходится дороже, чем кажется.
Наша позиция по опыту: автоматизируют устойчивые, повторяемые, критичные сценарии, которые уже стабилизировались и будут жить долго.
Разовые проверки, области в активной переделке и то, что требует человеческой оценки — визуал, удобство, «выглядит ли это правильно», — оставляют ручному тестированию. Автотест на нестабильной функции превращается в «флаки»: падает через раз, ему перестают верить, и он становится хуже, чем отсутствие теста.
Про деньги на этой теме. Отдельной услугой мы продаём аудит кода и архитектуры — 200–600 тыс. ₽ в зависимости от объёма; по его итогам видно, где регресс критичен и что автоматизировать первым. В проектах, которые ведём сами, QA и настройка регресса входят в работу и отдельной строкой не считаются. Если нужно понять состояние вашего продукта — напишите нам, оценим объём бесплатно.
| Критерий | Автоматизация | Ручной регресс |
|---|---|---|
| Стабильность сценария | Устойчивый, редко меняется | В активной переделке |
| Частота прогона | На каждый коммит/сборку | Разово или редко |
| Что проверяем | Логику, расчёты, потоки данных | Визуал, удобство, новые области |
| Окупаемость | На длинной дистанции | Здесь и сейчас, без вложений в код |
Автоматизация регресса — это вложение: тесты нужно написать и потом поддерживать. Оно окупается на продукте, который живёт и развивается долго, и не окупается на одноразовом проекте. Поэтому решение «что автоматизировать» — не техническое, а экономическое.
Где регресс живёт в процессе: CI/CD и Agile
В современной разработке регресс встроен в конвейер, а не проводится раз в квартал вручную. Логика гибких методологий — выпускать часто и маленькими порциями — без автоматического регресса невозможна: при релизе каждую неделю перепроверять всё руками нереально.
Типовая схема выглядит так. На каждый коммит или pull request автоматически гоняется быстрый набор — smoke плюс выборочный регресс по зоне изменения; если он падает, изменение не попадает в основную ветку. Перед релизом запускается более полный прогон. Это часть практики CI/CD (непрерывной интеграции и доставки), где автотесты — ворота, которые не пускают сломанный код дальше.
Объём автоматизации балансируют по «пирамиде тестов»: много быстрых юнит-тестов в основании, меньше интеграционных в середине и совсем немного медленных сквозных (E2E) наверху.
Регресс распределён по всем уровням, но опирается на нижние — они быстрые и дешёвые в поддержке. Как это устроено на всём жизненном цикле продукта, разбирали в статье про этапы разработки ПО. Перевёрнутая пирамида, где почти всё проверяется медленными сквозными тестами через интерфейс, — частая причина того, что прогон длится часами и тормозит релизы.
Три ошибки, которые убивают пользу регресса
Копить тесты и не чистить. Регрессный набор, в который годами только добавляют, превращается в болото: прогон длится вечность, половина кейсов проверяет то, чего уже нет, а разработчики начинают его игнорировать. Набор нужно пропалывать так же регулярно, как пополнять.
Автоматизировать нестабильное. Соблазн покрыть автотестами всё и сразу приводит к «флаки»-тестам, которые падают случайно. Пара таких — и команда перестаёт верить красному прогону, а это опаснее, чем отсутствие тестов: сломанное проезжает мимо, потому что «да оно всегда мигает».
Откладывать регресс на конец. Если проверять, не сломалось ли что-то, только перед самым релизом, поломки всплывают все разом и в худший момент. Регресс дешевле и спокойнее, когда идёт постоянно, — тогда каждая регрессия ловится рядом с вызвавшим её изменением, а не в общей куче под дедлайн.
Часто задаваемые вопросы
Это повторная проверка того, что раньше работало, после внесения в продукт изменений. Любая правка — новая функция, исправление ошибки, обновление библиотеки — может случайно сломать то, что уже было исправно, из-за связанности кода. Регресс ищет такие поломки, пока их не нашёл пользователь.
Ретест проверяет, что конкретный найденный баг действительно исправлен. Регресс проверяет, что при этом исправлении не сломалось что-то другое. Ретест сфокусирован на одном дефекте, регресс охватывает связанные функции. Их обычно делают вместе: сначала убеждаются, что баг закрыт, затем — что фикс не создал новых.
По объёму — полный (прогоняют весь регрессный набор, обычно перед крупными релизами), частичный (проверяют изменённую область и связанное с ней) и выборочный (только напрямую затронутые тесты). Рядом стоят smoke (беглая проверка, что сборка в принципе работает) и sanity (узкая проверка одной области после точечной правки).
Устойчивые, часто повторяемые и критичные сценарии — да: машина прогоняет их быстрее и без усталости, а на каждый релиз руками это делать нереально. Но области в активной переделке и проверки, где нужна человеческая оценка (визуал, удобство), разумнее оставить ручному тестированию. Автоматизация — это вложение в написание и поддержку тестов, оно окупается на долго живущем продукте.
После любых изменений в коде: добавили функцию, исправили баг, обновили зависимости, изменили конфигурацию. В зрелом процессе быстрый регресс запускается автоматически на каждый коммит или pull request, а более полный — перед релизом. Ждать финала проекта, чтобы проверить всё разом, — плохая идея: поломки тогда всплывают все сразу и в самый неподходящий момент.
Разработка с Code Pilots
Code Pilots — студия заказной разработки полного цикла: веб- и мобильные продукты с нетривиальной бизнес-логикой, интеграциями и высокими нагрузками. QA у нас — часть процесса с первого дня, а не аврал перед сдачей: продукты, которые мы ведём, развиваются годами, и регресс защищает уже работающее от каждого нового изменения.
Внутри — сильная in-house команда: аналитики, продуктовые дизайнеры, разработчики (Flutter и нативная разработка), QA-инженеры и DevOps. Мы выстраиваем регресс под жизненный цикл продукта: критичные сценарии автоматизируем и гоняем в CI/CD на каждое изменение, остальное закрываем ручным тестированием там, где это дешевле и надёжнее.
За счёт отлаженных процессов и глубоко внедрённого в разработку AI мы запускаем и развиваем продукты значительно быстрее рынка, не теряя в стабильности.
Нужно поставить тестирование на поток или собрать продукт, который не разваливается от каждой доработки, — расскажите о задаче, оценим под ваши цели. Обсудить проект →
