Module 01 · Les bases du test · 15 min
Exercice : un critère de bout en bout
La règle de longueur de la description dans ClaimTriage, de ses limites décidées à la liste complète de ses cas, chacun à son niveau.
Révision
De la leçon précédente : la fonction de routage renvoie queue-A pour tout sinistre critique. À quel niveau cela se prouve-t-il, et pourquoi pas à travers l'écran ?
La réponse du cours
Au niveau composant : la logique propre de la fonction en décide, ses entrées maîtrisées. À travers l'écran, la même vérification prendrait bien plus de temps et n'indiquerait rien de précis en cas d'échec.
La règle
Le product owner l'a décidée, et la décision est dans le backlog :
Longueur de la description. Soit un conseiller qui colle la description d'un sinistre, quand il l'envoie, alors ClaimTriage l'accepte si elle compte de 20 à 2 000 caractères, bornes comprises. Sinon, ClaimTriage la refuse avec l'erreur
DESC_LENGTH, indique au conseiller la plage acceptée, et n'envoie rien au modèle.
1. Les limites
2. Les cas
Listez les cas de test de cette règle. Pour chacun : ce qui est saisi, le résultat attendu, la technique d'où il vient, et son niveau. Puis nommez une question à laquelle la règle ne répond pas.
La réponse du cours
| Cas | Technique | Résultat attendu | Niveau |
|---|---|---|---|
| 300 caractères | Nominal, classe valide | Acceptée, la fiche est produite | Composant |
| 19 caractères | Limite, en dessous | DESC_LENGTH, plage affichée, rien d'envoyé |
Composant |
| 20 caractères | Limite, sur la borne | Acceptée | Composant |
| 2 000 caractères | Limite, sur la borne | Acceptée | Composant |
| 2 001 caractères | Limite, au-dessus | DESC_LENGTH, rien d'envoyé |
Composant |
| Description vide | Erreur, un extrême de la classe « trop courte » | DESC_LENGTH, rien d'envoyé |
Composant |
| 19 caractères à travers l'écran | Un cas système | Le conseiller voit l'erreur et la plage acceptée | Système |
| Rien n'atteint le modèle en cas de refus | Chemin d'erreur, la jonction avec le modèle | Aucun appel n'est fait au modèle | Intégration |
Questions auxquelles la règle ne répond pas, chacune à confirmer avec le product owner : les espaces au début et à la fin comptent-ils ? Les retours à la ligne sont-ils des caractères ? Un émoji compte-t-il pour un caractère ou deux ? Que dit exactement le message ? Un cas qui saisit " Dégât des eaux en cuisine. " a deux résultats attendus possibles tant que personne n'a décidé.
| Votre liste | ||
|---|---|---|
| A | Les quatre valeurs limites, la description vide, la plupart des cas au niveau composant, un ou deux plus haut pour ce qui n'existe que là, et au moins une question ouverte avec son responsable | ✅ |
| B | Les limites, mais tous les cas à travers l'écran | ⚠️ Les bons cas, au mauvais niveau : la règle est la logique propre de l'unité |
| C | Seulement des longueurs valides, ou seulement 0, 300 et 5 000 | ❌ Aucun cas sur une limite : un < écrit à la place de <= passe tous ces cas |
| D | Des résultats attendus ajoutés pour les questions ouvertes, comme « les espaces ne comptent pas » | ❌ Plausibles et inventés. Ils restent à confirmer |
3. Votre propre cas
Votre propre cas · Partie 1, module 01
Les cas de test d'un de vos critères
Choisissez un critère d'acceptation d'un produit sur lequel vous travaillez, avec au moins une limite. Réécrivez-le s'il n'est pas testable, et laissez « à confirmer » ce que personne n'a décidé, en nommant qui décide. Puis listez ses cas : chemin nominal, classes d'équivalence, valeurs limites, erreurs. Pour chaque cas, son résultat attendu, d'où vient ce résultat, et le niveau le plus bas qui peut le prouver.
Enregistré dans ce navigateur. Il rejoint votre bilan.
C'est la fin du premier module. Vous savez ce qu'un test prouve, d'où doit venir son résultat attendu, comment tirer les cas et à quel niveau les faire tourner. Le module suivant porte sur leur exécution : une campagne, ses verdicts, ses anomalies, et le moment où l'on vous demande où elle en est.