QA и тестирование

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

Регрессионное тестирование (regression testing) — это повторная проверка функций, которые уже работали, после изменений в коде. Его цель — убедиться, что новая функция или исправление ошибки не сломали того, что работало раньше.

Необходимость в нём возникает из-за связанности кода: изменение в расчёте скидки может неожиданно повлиять на формирование чека или отчёты. Чем больше система, тем менее заметны такие связи и тем важнее регулярно проверять старые сценарии.

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

Где применяется

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

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

Пример

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

Частые вопросы

Чем регрессионное тестирование отличается от повторной проверки?

Повторная проверка (ретест) подтверждает, что конкретную ошибку действительно исправили. Регрессионное тестирование проверяет, что это исправление ничего не сломало рядом. Ретест короткий и точечный, а регрессия охватывает все функции, которые работали раньше, и обычно выполняется набором тестов.

Как часто нужно проводить регрессионное тестирование?

Как минимум перед каждым релизом. Если тесты автоматизированы, их запускают после каждого изменения кода — это самый дешёвый способ сразу заметить поломку. Ручное регрессионное тестирование из-за трудоёмкости обычно проводят по сокращённому набору и только для важных сценариев.

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

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

Можно ли обойтись без регрессионного тестирования?

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

Обучение тестированию в OWU

Освойте профессию QA-инженера на практических курсах с менторами и реальными проектами.

Выбрать курс