Identifiez la structure d’un cas de test
Les cas de test, c'est comme donner son texte à un acteur.
Ils constituent une description détaillée des étapes à suivre pour tester une fonctionnalité ou un scénario.
Commençons par disséquer un cas de test pour comprendre de quoi ils sont composés :
Un nom : Il doit être descriptif et facile à comprendre par l’équipe de test.
Un identifiant : Il peut être de format numérique ou alphanumérique ; cela vous permet d’identifier de manière unique chaque test. Il revient à chaque organisation de définir un pattern.
Une description : Cela décrit les détails du cas de test, y compris les fonctionnalités ou les scénarios qui seront testés. Plus vous serez exhaustif, plus il sera aisé à la personne qui va lire de comprendre ce que vous lui demandez de faire.
Les prérequis : Ce sont les conditions préalables nécessaires pour exécuter le cas de test, comme la configuration du système, ou les données d’entrée.
Les étapes de test : Cela décrit les étapes à suivre pour exécuter le cas de test, de manière séquencée, y compris les interactions avec le système et les résultats attendus.
Cette description doit être claire, précise et non sujette à interprétation. Voici un exemple de ce qui est préférable et de ce qu’il faudrait éviter :
Préférable |
 |
Éviter |
 |
Chaque étape doit permettre de valider une seule vérification ; découpez en plusieurs étapes de test plutôt que de tout regrouper en une :
Préférable |
 |
Éviter |
 |
Vous pouvez noter que la tournure des phrases débute toujours par un verbe d’action. En utilisant cette pratique, vous permettez au testeur qui exécute votre cas de test, de comprendre explicitement ce que vous attendez de lui.
Les résultats attendus : c’est une description de la réaction du système suite aux actions que vous avez effectuées dans les étapes de test. Comme pour les étapes, il est préférable de n’avoir qu’un seul résultat attendu à contrôler.
Préférable |
 |
Éviter |
 |
Rédigez vos cas de test
Rédigeons à présent les cas de test dans le référentiel de test (la partie où sont stockés les cas de test).
Les tests à rédiger doivent être en lien avec le projet sur lequel votre équipe va travailler. Reprenez donc la liste de vos scénarios, et identifiez les cas de test nécessaires à rédiger.
Voici deux exemples de cas de test.
Premier cas :
Nom du cas de test : Ajout d'un produit dans le panier Identifiant : PAN-01 Objectif : Vérifier que l'utilisateur peut ajouter un produit dans le panier Prérequis : Le site web de e-commerce est accessible. L'utilisateur est connecté à son compte. Le produit que l'utilisateur souhaite ajouter est disponible sur le site web. Cas de test :
|
Dans ce premier cas, les étapes ne sont pas assez précises. Il n’est pas indiqué sur quel produit il faut se rendre, ni comment. Le testeur pourra donc prendre un chemin différent de celui que je souhaitais. Une des conséquences est qu’il ne sera pas dans les conditions où je voulais qu’il soit.
Second cas :
Nom du cas de test : Ajout d'un produit dans le panier Identifiant : PAN-01 Objectif : Vérifier que l'utilisateur peut ajouter un produit dans le panier Prérequis : Le site web de e-commerce est accessible. L'utilisateur est connecté à son compte. Le produit que l'utilisateur souhaite ajouter est disponible sur le site web. Cas de test :
|
Dans le cas numéro 2, j’ai explicité toutes les actions que je souhaitais que le futur testeur exécute. Je ne lui laisse pas de liberté dans ses actions, car j’ai souhaité qu’il passe par ce chemin bien précis.
Je sécurise ainsi l’objectif du test prévu.
Mettez à jour vos cas de test
Dans la phase de rédaction, une règle prédomine : Soyez économe.
Ne cherchez pas à réinventer la roue.
Prenez le temps de regarder dans le patrimoine de test si un cas de test n'existe pas déjà, qu’il vous suffirait de mettre à jour. Cela évitera la démultiplication du nombre de cas dans votre référentiel, et vous fera gagner un temps considérable.
Lors de votre mise à jour des cas de test, identifiez les étapes du test à mettre à jour.
Reprenons notre cas de test numéro 2 juste au-dessus, et imaginons que la méthode d’accès au panier change. On passe d’un pictogramme à un lien hypertexte.
Nous modifierons uniquement l’étape 7 :
7 | Cliquer sur le lien hypertexte “Panier” | Affichage du contenu du panier |
À vous de jouer !
Contexte
Toutes vos exigences ont été importées, et vous avez effectué votre relecture pour vous assurer qu’il n’en manquait pas.
Vous reprenez vos notes prises durant la définition des scénarios, et vous vous rappelez que les cas de test suivants, du patrimoine de test, sont à mettre à jour :
CDT-2 : Passer une commande client non authentifié.
CDT-3 : Passer une commande client authentifié.
Consignes
Rédigez les nouveaux cas de test nécessaires à la campagne, et mettez à jour ceux qui sont impactés.
En résumé
Le cas de test est une succession d'étapes ordonnées qui permet d’amener le testeur vers l’objectif du scénario.
Les cas de test doivent offrir au testeur la possibilité d’être autonome sur la compréhension et la démarche à suivre pour mener à bien son exécution.
Dosez la granularité de vos étapes et essayez de ne pas dépasser les 20 étapes, au risque de perdre le testeur lors de l’exécution.
Réutilisez le patrimoine existant lors de vos nouveaux projets, en mettant à jour les étapes correspondantes afin d’éviter la démultiplication de cas dans le référentiel, et pour gagner du temps.
Les cas de test étant rédigés, voyons maintenant comment les assembler pour construire nos scénarios.
