Краткий ответ

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

Если дефект проявляется только в новой версии, а на предыдущей версии при тех же условиях отсутствует, это сильное подтверждение регрессии. Без рабочей старой версии или другого достоверного эталона корректнее указывать не доказанную регрессию, а дефект с зафиксированным изменением поведения.

Исторический контекст

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

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

Постановка проблемы

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

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

Подробное решение

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

Интерпретация результатов обычно такая:

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

Для повышения надёжности сравнения полезно проверить изменение на нескольких независимых данных, если дефект может зависеть от состояния. Также следует связать дефект с конкретной версией, сборкой или изменением, но сама связь с коммитом является дополнительным свидетельством, а не заменой фактическому сравнению поведения.

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

Главный компромисс состоит в затратах на подготовку сопоставимого сравнения. Быстрая проверка только новой версии дешевле, но не позволяет надёжно установить происхождение дефекта; контролируемое сравнение занимает больше времени, зато повышает точность triage и анализа первопричины.

Ситуация из практики

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

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

Дефект классифицировали как регрессию, указали условие «сохранённая корзина» и приложили результаты сравнения. Это позволило разработчику искать изменение в обработке восстановления корзины, а не в общем расчёте скидки.

Что кандидаты часто упускают

Достаточно ли проверить старую версию один раз?

Нет, одного запуска может быть недостаточно, если результат зависит от случайных данных, состояния базы, кэша или внешней системы. Нужно убедиться, что сценарий действительно воспроизводим на старой версии, а различия между версиями не объясняются нестабильностью. Минимально следует повторить ключевую проверку или использовать несколько релевантных наборов данных.

Можно ли назвать дефект регрессией, если он появился после изменения требований?

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

Что делать, если предыдущая версия недоступна?

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