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

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

• Отложить релиз до исправления критичных проблем.
• Выпустить релиз с известными некритичными проблемами, задокументировав их.
• Выпустить фикс-версию (патч) сразу после релиза с исправлениями критичных проблем.

Параллельно с принятием решения:

• Фокусировать усилия на тестировании критичных частей функционала.
• Эффективно коммуницировать о статусе и найденных проблемах. Использовать общие доски задач (Jira, Azure DevOps и др.).
• Проанализировать причины постоянного появления новых проблем:
  • Недостаточное покрытие тестами (ручными или автоматизированными).
  • Проблемы с процессом разработки (код-ревью, культура написания кода).
  • Спешка в разработке и тестировании.
  • Недостаточная спецификация требований.

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