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 :

0

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 :

1

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

Publié par

3 réponses sur « L’écriture des cas de test »

  1. Bonjour,
    Félicitations déjà pour ton site qui est intuitif et permet d’avoir une mine d’informations sur le métier de testeur qui reste méconnu.
    Si je reprends ton exemple de cas de test : lire un mail sur une application Android, cela signifie t il qu’il y a autant de cas de tests qu’il y a de systèmes d’exploitation? J’avoue que je ne saisis pas la différence entre cas de test, jeu d’essai et scénario de test…
    J’espère que tu pourras m’apporter quelques éclaircissements, la littérature sur le sujet étant assez limitée.
    Merci par avance 😊

    Aimé par 1 personne

    1. Bonjour,
      Les tests peuvent vite se multiplier.
      Afin de s’assurer que l’on peut lire un mail sur TOUS les OS il faudra donc exécuter au moins un test sur chaque OS.
      Par rapport au « cas de test » et « scénario de test » c’est des notions très proches dont les définitions varient selon les équipes. D’après la définition ISTQB (lien vers le glossaire dans la partie lien utile), les cas de test sont les étapes d’un test. Un Test peut alors s’apparenter à un scénario de test.
      Le jeu d’essai quant à lui se rapproche du jeu de données. chaque test peut en avoir plusieurs (ex: test envoyer une PJ valide avec différentes PJ en données et plusieurs exécution du même test)

      J'aime

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s