Article mis à jour le : 16-11-2022
Quelques conseils pour la création d'un cahier de tests
Durant la phase de développement d'une application, les tests fonctionnels sont souvent négligés. En effet : cela prend du temps, on ne connait pas encore tout de l'application, ce n'est pas très intéressant pour les développeurs... On peut rencontrer plein de cas de figure.
Cependant dans le cadre d'un processus de qualité, tout cela est très important. Voici donc quelques règles et conseils quant à la rédaction d'un cahier de tests. Avant de continuer, je vous invite à vous rafraichir la mémoire en regardant la pyramide des tests pour comprendre où nous nous plaçons ici.
Le cahier de tests doit être créé très tôt. Et même avant la partie conception, et donc avant le codage à proprement parler. Les tests sont conçus en fonction du cahier des charges, de spécifications fonctionnelles ou techniques. Normalement, on doit faire du "Shift Testing Left", c'est à dire impliquer les testeurs le plus tôt possible. Concrètement qu'est-ce que cela donne ? Quand le besoin est présenté et exprimé, le testeur doit être là pour faire ses remarques et contribuer à repérer les points d'attention. Ensuite, quand les parcours utilisateurs sont spécifiés, le testeur peut commencer à écrire ses cas de tests.
Il existe des applicatifs, souvent développés en interne, mais sachez qu'un simple classeur Excel peut parfaitement remplir ce rôle. Cependant, il faut être très rigoureux, dans la gestion des éléments qu'il contient, dans la gestion des versions. Personnellement, j'apprécie Xray, intégré dans Jira, ce qui permet de faire le lien avec les tickets métiers et techniques.
Il existe plusieurs approches, à vous de choisir en fonction du contexte :
Voici quelques éléments que doit contenir le cahier de tests
Génériques :
Pour chaque test :
Le suivi est tout aussi important, car en cas d'échec aux tests le cahier va être transmis au developpeur voire aux concepteurs. Il faut donc versionner le cahier de tests pour pouvoir suivre l'évolution ou la régression éventuelle. Il est possible de tout faire sur un seul cahier si plusieurs champs dates ont été prévus, et plusieurs champs d'état du test (Essai N°1, Essai N°2...).
Tout cela peut être automatisé avec un outil adapté comme Xray. Grâce à lui, vous pouvez maintenir votre patrimoine de tests, les classer par sujet (récurrent ou un domaine fonctionnel précis), les lier aux tickets à valider. Enfin, du oint de vue du suivi et du contrôle qualité, on peut plus facilement retrouver ce qui a été testé sur tel ou tel sujet. C'est utile, par exemple dans le cas d'une anomalie non détectée, de reprendre ce qui a été testé et pour comprendre pourquoi on a "oublié" ceci et faire évoluer le patrimoine de tests.