O que faria se precisasse lançar uma versão, mas constantemente surgissem novos problemas, cuja correção leva a uma nova fase de regressão?

Avaliar a criticidade dos novos problemas. Determinar quais são críticos para o lançamento e quais podem ser corrigidos na próxima sprint ou patch. Realizar uma reunião conjunta da equipe de desenvolvimento, testes e gestão de produto para decidir os próximos passos. Opções:

• Adiar o lançamento até corrigir os problemas críticos.
• Lançar uma versão com problemas não críticos conhecidos, documentando-os.
• Lançar uma versão de correção (patch) imediatamente após o lançamento com as correções dos problemas críticos.

Paralelamente à decisão:

• Focar esforços nos testes das partes críticas da funcionalidade.
• Comunicar eficazmente o estado e os problemas encontrados. Utilizar quadros de tarefas comuns (Jira, Azure DevOps, etc.).
• Analisar as causas da aparição constante de novos problemas:
  • Cobertura de testes insuficiente (manual ou automatizada).
  • Problemas no processo de desenvolvimento (revisão de código, cultura de codificação).
  • Pressa no desenvolvimento e testes.
  • Especificação de requisitos insuficiente.

Se necessário, intensificar os testes de regressão, priorizando-os. Recursos adicionais ou redistribuição de tarefas dentro da equipa de testes podem ser necessários. Automatizar os cenários de regressão mais frequentes e críticos, se possível em prazos curtos. Após o lançamento, realizar uma retrospectiva para identificar e eliminar as causas raízes dos problemas.