Avant de commencer
- Terminez Mon premier rapport sur le plan TP-DOC — Boutique démo du jeu de démonstration.
- Générez le rapport sur la sous-suite statique TP-DOC — Parcours de commande. Vérifiez qu’il contient un cas réussi, un cas en échec et un cas non exécuté, avec une seule configuration.
- Vous devez pouvoir ouvrir les résultats et work items du projet. Ce parcours de diagnostic ne nécessite pas de modifier le barème ni les résultats.
Le barème est partagé au niveau du projet. Lisez celui indiqué dans le rapport ; ne changez pas les seuils pour reproduire une capture ou obtenir le verdict souhaité. Un rapport chargé depuis l’historique conserve le barème capturé lors de sa génération.
1. Relever le verdict et son contexte
Dans Rapport, repérez le bloc Qualité de la release. Notez :- le grade A–E et le score sur 100 ;
- le verdict GO ou NO-GO ;
- la ligne Barème … · seuil GO … ;
- la date et le périmètre du rapport.
2. Lire les règles qui ont réellement pesé
Cliquez sur Voir le détail. Lisez d’abord les composantes, puis les plafonnements et réserves affichés.
Détail dans TestPulse 2.73.1 pour ce jeu de 3 cas : réussite à 50 %, exécution à 67 %, grade D et score 67/100 avec le profil Strict. Les règles affichées expliquent le NO-GO ; le faible nombre de tests exécutés limite aussi la confiance.
Comparez ces taux aux planchers du profil réellement affiché :
Un plancher non atteint peut forcer le NO-GO et plafonner le grade à C. Le grade peut rester inférieur à C ; un plafond ne remonte jamais une note. Les profils ont aussi des poids et seuils de grade différents : ne déduisez pas un score identique de ces taux identiques. Une configuration personnalisée peut produire un autre détail : recopiez les règles de votre rapport plutôt qu’un score trouvé dans un exemple.
Contrôle : vous devez pouvoir associer chaque ligne de plafonnement à sa règle. Un bon score sur une autre composante ne compense pas un plancher de réussite ou d’exécution non atteint.
3. Retrouver la preuve derrière le chiffre
1
Examiner le cas en échec
Dans Résultats, repérez le cas en échec du scénario. Ouvrez son lien Run et contrôlez dans Azure DevOps le cas, le résultat et la configuration.Notez ce qui a été observé et ce qui était attendu. Revenez au rapport.Vous devriez voir : un résultat en échec identifiable, et pas seulement le nom d’une campagne contenant plusieurs résultats.
2
Vérifier les bugs dans la bonne source
Consultez les bugs du rapport et le détail de leur provenance. Par défaut, TestPulse utilise les bugs rattachés aux résultats d’exécution de la campagne, dans les runs qu’il a lus. Un bug seulement lié à une User Story ou à un cas de test n’est pas automatiquement un bug de campagne.Si le projet utilise l’autre mode, Liens des cas de test et des User Stories, appliquez ce contrat à votre analyse. La page Les bugs du rapport explique les deux modes et les limites de lecture.Vous devriez pouvoir dire : « Ce bug entre dans ce rapport parce que… », en montrant le lien et la source concernés.
3
Chercher un échec sans défaut et le travail restant
Consultez Échecs sans défaut. Dans le jeu minimal, le cas en échec y apparaît s’il n’a aucun bug reconnu par la source active. Par défaut, cette situation force également le NO-GO.Le bouton Ouvrir un bug ouvre un formulaire Azure DevOps prérempli. Il ne crée pas de bug à lui seul. Si vous décidez d’en enregistrer un dans un exercice ultérieur, vérifiez son rattachement à la source attendue : un titre similaire ne constitue pas une association à un résultat.Retrouvez ensuite le cas non exécuté. Désignez le travail à faire, sans le reclasser artificiellement pour améliorer les chiffres.
4. Lire les points de vigilance sans leur demander tout le verdict
Le bloc Points de vigilance met en avant les bugs bloquants ouverts, les exigences sans test et les User Stories du périmètre non exécutées. Il ne récapitule pas toutes les règles. Il peut donc ne présenter aucun de ces trois signaux alors que le rapport reste NO-GO à cause de son taux de réussite. Dans ce cas, revenez à Voir le détail. Pour un bug bloquant, vérifiez ensemble son état et sa sévérité. Avec les valeurs par défaut, un bug ouvert en sévérité Critique ou Élevée bloque la release. Le fait qu’un bug existe ne suffit pas à conclure qu’il est bloquant. Contrôle : aucune cause ne doit être inventée pour remplir un commentaire. Si seul le plancher de réussite est en cause dans votre périmètre, citez ce plancher et son résultat source.5. Formuler une conclusion utile
Préparez votre conclusion en quatre phrases :- Périmètre : quel plan, quelles suites et quelle date ?
- Constat : quelles règles actives empêchent le GO ?
- Preuves : quels résultats, bugs ou exigences pouvez-vous ouvrir ?
- Suite : qui analyse l’échec, qui exécute le cas restant, et quand régénérer ?
Le rapport TP-DOC porte sur trois cas et une configuration. Deux cas sont exécutés, dont un en échec : avec le profil Strict de cet exemple, les taux de réussite et d’exécution sont inférieurs aux planchers de 85 %. Le résultat en échec est consultable depuis la colonne Run ; le troisième cas reste à exécuter. Nous analysons l’échec et terminons ce périmètre, puis nous régénérons le rapport avant une nouvelle décision.Une correction de code, un bug clôturé ou une nouvelle exécution ne réécrit pas un ancien instantané. Après l’action sur les données source, générez un nouveau rapport pour refaire l’analyse.
Calcul et décision humaine : savoir les distinguer
Certaines équipes activent Autoriser l’override de décision GO/NO-GO dans les paramètres du projet. La section Décision de release permet alors de suivre le calcul ou d’appliquer une décision différente. Ce n’est pas nécessaire pour réussir cet atelier. Si un rapport porte déjà une décision manuelle, recherchez Calculé, Décidé (manuel), l’auteur, la date et la justification. Le grade reste celui du calcul. Un GO manuel qui franchit un plancher dur conserve un signal d’alerte. L’option est désactivée par défaut, et le profil Strict la laisse désactivée. Son absence ne constitue donc pas une panne. L’exercice de diagnostic ne demande pas de l’activer.Si vous voyez autre chose
À vous de jouer
Expliquez le NO-GO à un collègue sans commencer par la note : montrez d’abord l’échec et le cas restant, puis les règles qu’ils déclenchent. Demandez-lui quelle preuve lui manquerait pour réexaminer la release. Vous avez réussi si votre conclusion reste compréhensible sans la couleur du badge, si chaque cause peut être vérifiée et si vous savez distinguer une nouvelle génération d’une décision humaine sur le rapport existant.Barèmes et invariants
Retrouvez le calcul et les profils de référence.
Mener une session exploratoire
Consignez une observation, des preuves et un bug exploitable.