Que feriez-vous si vous deviez publier une version, mais que de nouveaux problèmes sont constamment découverts, et que leur correction entraîne une nouvelle phase de régression?

Évaluer la criticité des nouveaux problèmes. Déterminer lesquels sont des bloqueurs pour la sortie, et lesquels peuvent être corrigés lors du prochain sprint ou patch. Organiser une réunion conjointe de l'équipe de développement, de test et de gestion de produit pour décider des prochaines actions. Options :

• Reporter la sortie jusqu'à la correction des problèmes critiques.
• Lancer une version avec des problèmes non critiques connus, en les documentant.
• Lancer une version corrective (patch) immédiatement après la sortie avec les corrections des problèmes critiques.

Parallèlement à la décision :

• Concentrer les efforts sur le test des parties critiques de la fonctionnalité.
• Communiquer efficacement sur l'état et les problèmes rencontrés. Utiliser des tableaux de tâches communs (Jira, Azure DevOps, etc.).
• Analyser les causes de l'apparition constante de nouveaux problèmes :
  • Couverture de test insuffisante (manuelle ou automatisée).
  • Problèmes dans le processus de développement (revue de code, culture de codage).
  • Pression dans le développement et les tests.
  • Spécification des exigences insuffisante.

Si nécessaire, renforcer les tests de régression en leur donnant la priorité. Des ressources supplémentaires ou une redistribution des tâches au sein de l'équipe de test peuvent être nécessaires. Automatiser les scénarios de régression les plus fréquents et critiques, si cela est possible dans des délais serrés. Après la sortie, réaliser une rétrospective pour identifier et éliminer les causes profondes des problèmes.