Analyse d'impact des versions et planification de la régression
Cas d'usage illustratif, pas une étude de cas.
Les changements d'une version sont rapprochés des configurations, intégrations et tests concernés ; le responsable de livraison décide du périmètre et autorise ou refuse la mise en production.
Le problème
Les versions des éditeurs et nos propres changements arrivent selon un calendrier que nous ne contrôlons pas. Nous lisons les notes de version, devinons ce qui pourrait casser, et testons soit tout, soit ce dont nous nous souvenons. Des défauts atteignent quand même les utilisateurs.
Comment cela fonctionne aujourd'hui
Lorsqu'une version est annoncée, un analyste lit les notes et envoie un e-mail à l'équipe sur tout ce qui semble pertinent. Les testeurs choisissent des scripts dans un dossier partagé en fonction de leur expérience. Les partenaires d'intégration sont prévenus tard. Après la mise en production, les problèmes sont remontés jusqu'à des changements que personne n'avait signalés.
Voir le scénario
Flux de travail illustratif. Sous-titré.
Transcription
- Les notes de version arrivent, mais l'équipe devine quoi tester. Les changements manqués deviennent des incidents en production.
- Le planificateur relie les changements de version aux applications et aux tests affectés, souligne les lacunes de couverture et propose quoi tester et comment déployer.
- Le responsable de livraison décide ce qui est testé ou différé. Le plan est revu, et les résultats des tests conditionnent la mise en production.
- Mesuré sur couverture de tests et défauts échappés. Cas d'usage illustratif. Parlons du vôtre.
Flux de travail proposé
- Ingérer les notes de version et les enregistrements de changement pour les applications du périmètre
- Relier chaque changement aux configurations, personnalisations et intégrations qu'il peut toucher
- Faire correspondre les zones affectées à l'inventaire de tests existant et mettre en évidence les lacunes
- Rédiger une proposition de périmètre de régression et de séquence de déploiement
- Présenter le plan au responsable de livraison pour approbation avant que les tests et le déploiement ne se poursuivent
Où une personne garde le contrôle
- Le responsable de livraison approuve le périmètre de régression et le déploiement
- Les changements qui ne peuvent pas être reliés sont signalés pour évaluation manuelle plutôt qu'ignorés
- Les défauts échappés sont réinjectés dans la cartographie et l'inventaire de tests
Les correspondances de plateformes indiquent les environnements dans lesquels évaluer cette idée. La mise en œuvre réelle dépend de la configuration, des licences, des API, des données et des autorisations. Les bénéfices sont exprimés de manière qualitative ; toute affirmation chiffrée exige une base de référence documentée.