Можно ли отказаться от регрессионного тестирования, и в каких случаях это может быть оправдано?

Отказаться от регрессионного тестирования в классическом понимании крайне рискованно. Однако, можно оптимизировать или минимизировать его в определенных случаях:

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

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

Более оправданным является оптимизация регрессионного тестирования:

1. Автоматизация: Максимальное покрытие критичных и часто изменяемых функциональностей автоматизированными тестами.

   python

2. Приоритизация: Сосредоточение на наиболее критичных и затронутых изменениями областях приложения.
3. Риск-ориентированный подход: Определение тестовых сценариев на основе оценки рисков внесенных изменений.
4. Смоук-тестирование: Проведение быстрого набора тестов для проверки базовой работоспособности системы после деплоя.
5. Избирательное регрессионное тестирование: Выбор подмножества регрессионных тестов, актуальных для данного изменения.

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