Un cas de test, ou test case, est un ensemble de conditions préalables, de données d'entrée, d'actions et de résultats attendus, élaboré dans le but de vérifier le bon fonctionnement d'une évolution ou d'un produit.
Les cas de tests sont rédigés et exécutés par les Quality Analysts ou parfois par les Product Owners, et permettent de détecter des bugs ou d'affirmer que ce qui a été testé est conforme aux attentes.
C’est grâce aux cas de tests que l’on peut s’assurer qu’une fonctionnalité a été testée dans son ensemble.
On comprend donc qu'il est important d'avoir des cas de tests complets, afin de s'assurer de la qualité de ce qui sera ensuite livré. Pour cela, il existe quelques règles et astuces de rédaction des cas de tests qui vous permettront une couverture complète de vos User Stories.
Les cas de tests ont quelques règles de structure à respecter afin d'être le plus exhaustif, complet et clair possible. Le critère le plus important d'un bon cas de test, est qu'il doit être compréhensible par tous. N'importe qui doit être capable de le comprendre et de l'exécuter, même un QA qui en est à son premier jour de travail, ou qui vient d'arriver dans une nouvelle entreprise.
Un cas de test doit :
Et par-dessus tout, les cas de tests doivent assurer la couverture complète de la User Story, et pour cela, il faut se baser sur les exigences de l'US.
Les exigences sont les comportements attendus grâce à l’évolution, ce sont tous les éléments contenus dans la User Story auxquels il va falloir prêter attention, et qui seront nécessaires pour la validation de ses développements.
Il est important de partir de ces exigences pour rédiger un cas de test, d'abord parce que cela permettra de s'assurer de la bonne couverture de l'US et d'être sûr qu'aucun élément n'a été omis et qu'il n'y aura pas de trou dans la raquette.
Partir des exigences permet aussi de gagner du temps, d'être efficace dans la rédaction des cas, et ainsi de respecter le Time to Market (durée de développement et de construction du produit, ou date à laquelle le produit doit être livré ; plus il est court plus on a de chances de devancer les concurrents).
Des cas de tests rédigés à partir des exigences permettent non seulement de couvrir toute l'US, mais aussi de ne pas partir dans tous les sens et de ne pas tester quelque chose qui serait en dehors du scope de l'évolution, en dehors du périmètre de l'US.
Des cas de tests incomplets peuvent laisser passer des bugs, et avec des cas non pertinents on prend le risque de passer à côté d'éléments clés exprimés dans les exigences.
Tout d'abord, pour bien comprendre le périmètre et les exigences, il est nécessaire de bien lire l'US, et si besoin ne pas hésiter à poser des questions au PO qui l'a rédigée. Il peut arriver qu’une US soit incomplète, qu'elle contienne des incohérences ou tout simplement qu’elle soit complexe.
Ensuite, la première étape de la rédaction des cas de tests sera de rédiger des critères d'acceptance. Ces critères d’acceptance peuvent être rédigés et ou validés avec toute l’équipe (devs, QA, PO) afin de s’assurer que les grandes lignes de l’US sont bien comprises par tout le monde, et que les cas de tests iront dans le bon sens. Pour bien rédiger des critères d’acceptance, le langage Gherkin est idéal.
L’étape suivante, et probablement l’une des plus importantes, sera de créer une matrice de couverture. La matrice de couverture permet de croiser les différents cas d’utilisation et leurs variables. L’objectif de cette matrice et d’assurer une couverture complète avec un maximum de croisements entre les différentes variables, et d’avoir une idée du nombre de cas de tests à rédiger.
Exemple :
Voilà la matrice de couverture pour tester le bon fonctionnement d’une fenêtre :
N’hésitez pas à faire valider votre matrice par d’autres testeurs, votre lead test ou votre PO !
Maintenant vous pouvez commencer la rédaction de vos cas ! Ayez toujours en tête le périmètre de votre US, afin de vous concentrer sur les éléments importants et de ne pas vous attarder sur ce qui est hors scope.
D’autre part, il peut être intéressant de tester d'abord les fonctionnalités clés de l'US, les exigences prioritaires, les plus importantes et les plus critiques, afin de repérer le plus rapidement possible les bugs les plus bloquants ou critiques. Et ensuite vous pourrez rentrer dans le détail des fonctionnalités.
Une fois que vous avez terminé la rédaction de vos cas, l’idéal est de bien relire l’US afin d’être sûr de ne pas avoir oublié un élément.
Pour finir, une fois que vous aurez terminé de tester votre fonctionnalité, vous pouvez effectuer quelques tests exploratoires afin de vérifier que votre évolution n’a pas créé de régression.
Toutefois, il est possible de nuancer un peu ce qui a été dit précédemment, dans le sens où le plus important n'est pas de tester au maximum, mais plutôt de se concentrer sur la qualité.
Il faut garder en tête que l’objectif final est de délivrer une fonctionnalité qui réponde aux attentes des utilisateurs. Le client se fiche de savoir combien de cas de tests, vous avez passé, en revanche, il se soucie de la qualité de la fonctionnalité et de savoir si elle répond correctement à ses besoins.
À vos matrices !
Ce qu'il faut retenir :
Le spécialiste du conseil fullstack Produit : Strategy, Discovery & Delivery !
