L’écriture des cas de test

Je tenais à écrire cet article car trop souvent j’ai travaillé avec des cas de tests mal écrits et que cela peut coûter très cher (en temps et en argent) au projet.

Les cas de tests sont la base de travail des testeurs et donc le livrable de test le plus important. Pour les tests comme pour tout il faut partir sur de bonnes bases (cela ne sert à rien d’apprendre les multiplications lorsque l’on ne sait pas encore compter) c’est pourquoi il faut faire très attention et être rigoureux dans l’écriture de ces cas (manuels ou automatisés). Ce n’est pas parce que c’est simple qu’il faut le négliger !

Les inconvénients des cas de tests mal écrits sont nombreux voici les plus importants :

·        Les tests sont sujets à interprétation selon la personne qui les exécute.

·        Les tests ne vérifient pas ce que l’on veut et ne sont donc pas fiable, vérifier la présence d’un mot pour s’assurer l’affichage d’une page peut être une bonne idée… sauf si ce mot apparaît sur la page précédente

·        Les tests ne sont pas stables : vérifier le titre du premier mail d’une boite de réception est une mauvaise idée, rien ne prouve que d’autres mails ne soient pas arrivés.

·        Les tests sont difficilement maintenables, il faut souvent les réécrire totalement lorsque la fonctionnalité évolue.

·        Beaucoup de temps perdus avec des bugs rejetés. C’est principalement pour mesurer la qualité des tests que l’indicateur des bugs rejetés est particulièrement intéressant.

·        Les tests sont difficilement automatisables : C’est le résultat de l’ensemble des problèmes relevés précédemment.

Des cas de tests mal écrits impactent donc la qualité de l’application, son temps avant mise sur le marché (Time to Market) et souvent les relations entre les différents membres de l’équipe.

Comment bien écrire un cas de test manuel ?

Pour écrire un cas de test il faut que l’écriture soit standardisé, qu’elle soit sensiblement la même quel que soit le testeur qui ait écrit le cas. Il faut également que n’importe quelle personne du projet soit capable d’exécuter ce cas, l’exécution des cas de test ne doit pas être un goulot d’étranglement ni dépendre de la personne qui l’exécute (cela arrive malheureusement assez fréquemment) !

Le principe de base de toute écriture d’un cas de test manuel est :

C’est-à-dire que chaque étape d’un cas se définit par 1 action précise engendre 1 résultat précis.

Exemple de cas de test : lire un mail sur une application android :

Ici l’exemple est simple mais si le principe de cet exemple est appliqué rigoureusement alors les cas de tests écrits ne seront pas sujets à interprétation. En appliquant ce principe j’ai réussi à faire exécuter du premier coup des cas complexes (15+ étapes, à un testeur envoyé en renfort (qui travaillait à distance) et ayant rejoint le projet 1 semaine avant et ne connaissant pas l’application sur laquelle je travaillais).

Pour tout cas de test manuel je recommande vivement une revue. Une revue même informelle peut permettre d’éviter certaines erreurs, il ne faut jamais négliger les tests statiques.

Comment bien écrire un cas de test automatisé ?

Pour écrire de bon cas de tests automatisés il faut partir d’une bonne base… et donc de tests manuels bien écrits. En effet, encore plus que pour les tests manuels les tests automatisés font une action puis une vérification (il peut y avoir plusieurs actions avant la vérification, par exemple lorsque l’on remplit un formulaire).

Ensuite, les cas de tests automatisés sont des cas de tests « codés », il faut donc comme pour le code des développeurs, avoir :

·        Des conventions d’écritures, le cas doit être rapidement compris de tous.

·        Des bonnes pratiques communes à l’équipe.

·        Des cas bien commentés

·        Un revue lorsque le cas est écrit

Tout cela permet d’avoir des cas plus facilement analysable en cas d’échec et plus facilement maintenable (la connaissance n’étant pas que chez la personne ayant développé le cas)

Conclusion :

Avoir des cas de tests bien écrits ne coûte pas forcément plus cher à l’écriture, par contre cela permet d’éviter de nombreux déboire et de travailler dans de meilleures conditions. Je ne compte plus ne nombre de bugs rejetés que j’ai eu car l’erreur venait du test ou que ce dernier était sujet à interprétation, je ne compte plus les cas que j’ai dû totalement réécrire et malheureusement je ne compte plus le nombre de bugs passés en production car le cas de test qui devait le couvrir était soit mal écrit soit non maintenu.

N’hésitez pas à rejoindre le groupe Le métier du test

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles