Ответ
Полное регрессионное тестирование после каждого изменения часто становится непрактичным из-за высоких затрат. Отказ от него — это оптимизация процесса.
Основные причины:
- Высокая стоимость: Требует значительных временных и человеческих ресурсов для выполнения.
- Длительное время выполнения: Замедляет частоту релизов, что критично в современных Agile/DevOps-практиках.
- Сложность поддержки: Большое количество ручных тест-кейсов быстро устаревает и требует постоянного обновления.
- Закон убывающей отдачи: Многие тесты дублируют друг друга или проверяют маловероятные сценарии.
Альтернативные стратегии:
- Выборочный (санитарный) регресс: Тестирование только областей, затронутых изменениями, и связанных с ними модулей.
- Risk-based testing: Фокус на тестировании наиболее критичных для бизнеса функций, где сбой нанесёт максимальный ущерб.
- Автоматизация smoke- и sanity-тестов: Быстрая автоматизированная проверка ключевых сценариев в CI/CD-конвейере.
- Пирамида тестирования: Делается ставка на большое количество быстрых и стабильных модульных и интеграционных тестов, а E2E-тесты используются точечно.
Пример: В проекте с ежедневными деплоями полный ручной регресс невозможен. Вместо этого используется набор из 500+ модульных тестов, 100+ API-тестов и 20 критических E2E-сценариев, запускаемых автоматически.