Module 01 · Les bases du test · 12 min
Un critère qu'on peut tester
Ce qui rend un critère d'acceptation testable, la forme Soit / Quand / Alors, et que faire d'une phrase qui n'est pas encore testable.
Révision
De la leçon précédente : la suite était verte depuis trois mois. En une phrase, pourquoi ne pouvait-elle pas attraper le bogue de routage ?
La réponse du cours
Ses files attendues avaient été recopiées depuis ce que renvoyait le service : elle comparait le service à lui-même. Seuls des résultats attendus tirés d'une spécification que quelqu'un possède, ici la table de routage, peuvent attraper un défaut.
D'où vient le résultat attendu
Dans une équipe produit, le résultat attendu d'un test vient des critères d'acceptation d'une user story. Si le critère est flou, le testeur doit inventer le résultat attendu, et vous avez vu dans la leçon précédente ce que vaut un résultat attendu inventé.
Le premier test a donc lieu avant qu'aucun test soit écrit : ce critère peut-il être testé tel qu'il est écrit ?
Les trois parties d'un critère testable
- Une situation de départ : qui, avec quelles données, dans quel état.
- Une action : ce qui se passe.
- Un résultat observable : une valeur, un message, un code, un enregistrement, un temps mesuré quelque part, et rien qui dépende du goût.
Deux personnes qui le lisent doivent arriver au même verdict sur la même exécution. « Rapide », « intuitif », « correct », « convivial » échouent à ce test : deux testeurs ne seront pas d'accord, et le développeur sera d'accord avec celui qui lui donne raison.
La forme Soit / Quand / Alors oblige à écrire les trois parties :
# language: fr
Scénario: Refuser un sinistre automobile à un conseiller sans le droit automobile
Soit un conseiller dont le rôle n'a pas droit à la ligne automobile
Quand il ouvre le sinistre automobile 5003 dans ClaimTriage
Alors ClaimTriage renvoie l'erreur ENTITLEMENT_DENIED
Et aucune fiche de tri n'est produite
Vous n'êtes pas obligé d'écrire chaque critère sous cette forme. Vous devez pouvoir le faire.
Ce que vous ne pouvez pas rendre testable seul
Souvent, un critère est flou parce que personne n'a encore décidé le chiffre ou la règle. « La description ne doit pas être trop longue » : trop longue, c'est combien de caractères ? Ce n'est pas une décision de testeur, et inventer un chiffre plausible est le piège de la leçon précédente sous une autre forme : un chiffre que personne n'a approuvé se lit ensuite exactement comme un chiffre approuvé.
La version honnête laisse la décision ouverte et nomme qui la prend :
Soit un conseiller qui colle une description de plus de ‹longueur maximale, à confirmer avec le product owner› caractères, quand il l'envoie, alors ClaimTriage la refuse avec l'erreur
DESC_LENGTHet rien n'est envoyé au modèle.
Ce critère n'est pas terminé, et il le dit. Il est quand même bien plus utile que « pas trop longue » : tout le monde voit ce qui manque et qui doit le fournir.
1. Quatre critères
Voici quatre critères d'acceptation du backlog de ClaimTriage :
- AC1. La fiche de tri est renvoyée en moins de 3 secondes pour 95 % des demandes, mesuré sur l'environnement de test.
- AC2. Le résumé de la fiche doit être convivial.
- AC3. Soit un conseiller sans le droit automobile, quand il ouvre un sinistre automobile, alors il reçoit l'erreur
ENTITLEMENT_DENIEDet aucune fiche. - AC4. Le routage doit être correct.
2. Réécrivez-en un
Ce critère est dans le backlog : « La description du sinistre doit être assez courte et le tri doit être rapide. » Réécrivez-le pour qu'on puisse le tester. Vous ne connaissez aucune décision sur les longueurs ni sur les temps.
La réponse du cours
Il contient deux comportements : il devient donc deux critères. Et comme personne n'a décidé les chiffres, ils restent à confirmer, avec leur responsable :
Longueur. Soit un conseiller qui colle une description de moins de ‹longueur minimale› ou de plus de ‹longueur maximale› caractères, quand il l'envoie, alors ClaimTriage la refuse avec une erreur documentée et rien n'est envoyé au modèle. (Longueurs à confirmer avec le product owner.)
Temps. Soit une description valide, quand le conseiller l'envoie, alors la fiche de tri est renvoyée en moins de ‹temps› secondes pour ‹part› des demandes, mesuré sur ‹environnement›. (Valeurs à confirmer avec le product owner ; l'environnement de mesure avec le responsable des tests.)
| Vous avez écrit | ||
|---|---|---|
| A | Deux critères, chacun avec un résultat observable, et les chiffres laissés à confirmer avec qui les confirme | ✅ |
| B | Deux critères avec des chiffres que vous avez choisis, comme 2 000 caractères et 3 secondes | ⚠️ Testable, et inventé. Demandez avant d'écrire un chiffre : la règle de la dernière leçon part d'un chiffre décidé |
| C | Un critère qui dit encore « rapide » ou « assez courte » | ❌ Deux testeurs ne seraient toujours pas d'accord sur le verdict |
Le product owner a depuis décidé les longueurs : une description est acceptée de 20 à 2 000 caractères, bornes comprises. Vous vous servirez de cette décision dans la dernière leçon de ce module.