Module 02 · Mener une campagne · 12 min
Du KO à l'anomalie
Qualifier un KO avant que quiconque ouvre un ticket, rédiger une anomalie qu'un développeur peut reproduire, et ne la fermer que sur un nouveau test réussi.
Révision
De la leçon précédente : un test est ignoré avec la raison « flaky, to look at later ». Que prouve le rapport sur le comportement qu'il couvre ?
La réponse du cours
Rien. Un test ignoré n'a ni réussi ni échoué : c'est un manque à signaler, et « instable » n'est pas une raison de l'ignorer. Un test instable compte comme un échec tant qu'il n'est pas corrigé.
Un KO n'est pas encore une anomalie
Un KO dit que le produit et le résultat attendu ne sont pas d'accord. Il ne dit pas encore lequel des deux a tort. Avant que quiconque rédige une anomalie, le KO est qualifié :
| Le problème est | La preuve | Ce qui suit |
|---|---|---|
| Dans le produit | Le résultat attendu vient d'une spécification que quelqu'un possède, et le produit s'en écarte | Une anomalie, confiée à l'équipe qui corrige le produit |
| Dans le test | Le résultat attendu n'a jamais été spécifié, ou il est périmé, ou le test vérifie un détail que personne n'a demandé | Le test est corrigé, et la raison consignée |
| Dans l'environnement | Connexion refusée, données manquantes, service non lancé : le test n'a jamais atteint le produit | On répare l'environnement, on relance, on garde les deux exécutions |
Il existe un quatrième cas, plus rare et important : le produit fait exactement ce qui a été spécifié, et la spécification a oublié quelque chose. Ce n'est pas un défaut du code. C'est une carence, et elle repart vers le product owner comme une exigence manquante, pas vers un développeur comme un bogue.
Une anomalie que l'on peut reproduire
Une anomalie s'écrit pour un développeur qui n'était pas là. Il doit pouvoir voir le problème sans rien vous demander. Elle contient :
- un titre qui dit ce qui se passe, pas ce que vous en pensez : « Sinistre voyage critique routé vers queue-travel », pas « Routage cassé » ;
- les étapes, avec les données exactes : quel sinistre, quelle ligne de produit, quelle urgence, quel build, quel environnement ;
- le résultat attendu, et sa source : la table de routage, sa version, sa section ;
- le résultat observé, exactement tel qu'il est apparu, avec la capture ou la ligne de journal ;
- la gravité : à quel point c'est grave pour les personnes qui utilisent le produit. La priorité, c'est-à-dire dans quel délai corriger, est un autre champ, et en général la décision du product owner.
Elle ne contient pas la correction. Deviner la cause dans l'anomalie oriente le développeur avant qu'il ait regardé.
La fermer
Une anomalie se ferme sur une nouvelle exécution réussie, sur un build qui contient la correction. Pas sur « c'est corrigé, faites-moi confiance », ni sur un test modifié pour passer. Cette exécution devient un cas de non-régression, gardé pour de bon dans la suite, pour que le même défaut ne puisse pas revenir sans qu'on le voie.
Rédigez-en une
Dans CAMP-03, le cas CT-02 est KO : sinistre 7731, ligne voyage, urgence critique, build 2.3.0-142, environnement de test. La fiche indique queue-travel. Rédigez l'anomalie.
La réponse du cours
Titre. Sinistre voyage critique routé vers queue-travel au lieu de queue-A
Étapes. Sur l'environnement de test, build 2.3.0-142 : en tant que conseiller qui a droit à la ligne voyage, ouvrir le sinistre 7731 (voyage, urgence
critical) et lire la file sur la fiche de tri.Attendu.
queue-A. Source : table de routage, manuel d'exploitation, « critical va en queue-A quelle que soit la ligne de produit ».Observé.
queue-travel. Capture de la fiche jointe. La même chose se produit pour les sinistres de responsabilité civile critiques (R-07 dans la suite de routage).Gravité. Critique : un sinistre urgent attend dans une file ordinaire. Priorité : à fixer par le product owner.
| Votre anomalie | ||
|---|---|---|
| A | Données et build exacts, résultat attendu avec sa source, résultat observé tel quel, gravité distincte de la priorité, aucune correction devinée | ✅ |
| B | Tout cela, plus « probablement le if sur la ligne de produit dans la fonction de routage » |
⚠️ Retirez la supposition. Si vous connaissez la cause, dites-la au développeur, pas dans l'anomalie |
| C | « Le routage est faux pour les sinistres voyage, merci de corriger » | ❌ Ni données ni source : le développeur commencera par vous demander tout ce que vous saviez |
Une fois cette anomalie corrigée, quel cas le prouve, et que devient ce cas ensuite ? CT-02, relancé sur le build corrigé : un OK ferme l'anomalie, et CT-02 reste dans la suite comme cas de non-régression.