Qu'est-ce qu'un cas de test ? Comment en écrire un que quelqu'un d'autre peut exécuter

Un cas de test est une seule vérification, écrite pour que quelqu’un qui ne l’a pas rédigée puisse l’exécuter et obtenir la même réponse. Il nomme un état de départ, les étapes à suivre et ce qui doit se produire. Si deux personnes peuvent l’exécuter et ne sont pas d’accord sur sa réussite, il n’est pas terminé.

C’est toute l’idée, et c’est la même idée qu’un rapport de bug pris par l’autre bout. Un rapport de bug dit “voici comment faire en sorte que quelque chose casse”. Un cas de test dit “voici comment vérifier que cela fonctionne”.

Ce qu’il contient

Six parties, et seulement trois sont les intéressantes.

• Un identifiant pour pouvoir le citer dans un rapport de build ou une conversation
• Un titre qui dit ce qui est vérifié, pas ce sur quoi on clique
• Préconditions : l’état dans lequel le monde doit être pour que l’étape un ait un sens
• Étapes, numérotées, chacune une action
• Résultat attendu, assez précis pour pouvoir être faux
• Résultat obtenu, rempli au moment de l’exécution

Les trois qui décident s’il fonctionne sont les préconditions, le résultat attendu et le titre. Les étapes sont faciles. Savoir quel état le test suppose, et ce que “correct” veut dire assez précisément pour qu’on puisse en discuter, voilà le travail.

Écrire le titre

Un titre se lit dans une liste de deux cents, il devrait donc dire ce qui est vérifié.

Faible

Tester la page de connexion

Mieux

La connexion est refusée, avec un message, quand le mot de passe est faux

Le second vous dit ce qu’il couvre, ce qu’un échec voudrait dire, et s’il fait doublon avec celui d’en dessous. Le premier ne vous dit rien, et dans six mois personne ne saura s’il couvre le message d’erreur ou non.

Écrire les étapes

Numérotez-les et mettez exactement une action dans chacune. Le test n’est pas l’endroit où être économe.

Titre :         La connexion est refusée, avec un message, quand le mot de passe est faux
Préconditions : Un compte confirmé existe pour ada@example.com
Étapes :
  1. Ouvrir /login
  2. Saisir ada@example.com dans le champ e-mail
  3. Saisir wrongpassword dans le champ mot de passe
  4. Cliquer sur Se connecter
Attendu :       La page reste sur /login, affiche "E-mail ou mot de passe incorrect",
                et le champ mot de passe est vidé

Remarquez ce que le résultat attendu ne dit pas : “une erreur apparaît”. Trois implémentations différentes satisfont cette phrase et deux d’entre elles sont fausses. Il nomme aussi ce qui n’aurait pas dû se produire, à savoir aucune navigation, car un test qui ne vérifie que le message passera sur une page qui affiche le message et connecte quand même l’utilisateur.

Ce qui abîme un cas de test

Il dépend du test précédent. Un cas qui ne passe que si le précédent a tourné d’abord ne peut pas être exécuté seul, ne peut pas être réordonné, et s’effondre en bloc dès que quelque chose casse tôt. Chaque cas met en place ses propres préconditions.

Il vérifie six choses. Quand il échoue, vous apprenez que l’une des six est fausse. Découpez-le.

Il décrit l’interface au lieu du comportement. “Cliquer sur le bouton bleu en haut à droite” casse quand le bouton bouge ; “Envoyer le formulaire” non.

Son résultat attendu est un haussement d’épaules. “Fonctionne correctement”, “conforme”, “aucune erreur” - tout cela veut dire que c’est la personne qui exécute qui décide, ce qu’un cas de test existe précisément pour éviter.

Il teste ce qui ne peut pas échouer. Un cas qui vérifie qu’un titre statique affiche les bons mots coûte du temps à chaque exécution, pour toujours. Mettez l’effort là où vit le comportement.

Cas manuels et cas automatisés

La même discipline, une économie différente. Un cas automatisé tourne à chaque build et doit être précis, sinon il sera instable ; un cas manuel est exécuté par une personne qui peut faire preuve de jugement, ce qui est à la fois sa force et la raison pour laquelle deux personnes tirent deux réponses d’un cas vague.

Écrivez des cas manuels pour ce qui demande du jugement - est-ce que cette mise en page semble fausse, est-ce que ce message a du sens - et automatisez ce qui a une entrée connue et une réponse connue. Et gardez les manuels plus courts que vous ne le pensez : un cas de quinze étapes se fait sauter en son milieu par quiconque l’exécute pour la neuvième fois.

Quand l’un d’eux échoue

Un cas de test en échec est le début d’un rapport de bug, et il part avec de l’avance sur la plupart : les étapes sont déjà écrites, le résultat attendu est déjà énoncé, et les deux sont dans une langue sur laquelle quelqu’un peut agir.

Ce qu’il ne porte pas, c’est le contexte de la machine où il a échoué - le navigateur, la console, les requêtes derrière la page. C’est l’écart entre “le cas de test 47 a échoué” et un rapport avec lequel un développeur peut travailler.

Attachez l’identifiant du cas au rapport et les deux restent reliés : celui qui le corrige peut exécuter la même vérification, et celui qui exécutera la vérification à la version suivante verra qu’elle a échoué une fois. Le guide du rapport de bug couvre le reste de ce dont ce rapport a besoin.

La version courte

Une vérification par cas. Des préconditions qu’il met en place lui-même. Des étapes que quelqu’un d’autre peut suivre. Un résultat attendu assez précis pour que deux personnes ne puissent pas être en désaccord sur sa survenue. Tout le reste n’est que mise en forme.