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

Что хотят услышать интервьюеры:

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

Определение:

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

Пример использования:

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

Пояснение кода:

Код не требуется, так как это процесс тестирования, а не кодовая конструкция. Логика применения такая:

1. Вносятся изменения в продукт.
2. Оценивается риск влияния на существующий функционал.
3. Запускается набор регрессионных тестов: минимальный smoke, затем расширенный регресс при необходимости.
4. Если изменения крупные или затрагивают ядро системы, регрессия проводится чаще и глубже; если изменения точечные, достаточно выборочной проверки.

Ключевые моменты:

• Регрессия проводится не по жёсткому расписанию, а по событию изменения продукта.
• Минимум — перед релизом и после значимых исправлений.
• Чем больше зона влияния изменения, тем шире регрессионный набор.
• В автоматизации часто выделяют быстрый smoke-пакет и более полный регресс.
• Полная регрессия на каждый мелкий багфикс обычно неэффективна; нужен риск-ориентированный подход.