Petits trucs de testeur: reproduire une anomalie

Introduction

Lorsque l’on fait nos tests, scriptés ou non, il n’est pas rare de rencontrer une anomalie (et heureusement car trouver des défauts fait partie des objectifs des tests selon l’ISTQB).

Notre réflexe de testeur est alors de créer une fiche d’anomalie afin de donner de l’information. Nous voilà donc en train d’écrire notre fiche avec une criticité, le test relié, le scénario, ce que l’on attendait, ce que l’on a eu, des traces d’utilisations, des impressions d’écrans… Bref une fiche bien remplie afin que le développeur puisse corriger sans difficulté cette anomalie.

Malheureusement, 1 jour après, le développeur renvoie notre ticket sous prétexte que l’anomalie est « Non reproductible ». Le problème ne vient pas du développeur, je le connais il est consciencieux et s’il met « non reproductible » c’est qu’il n’a vraiment pas réussi à reproduire le bug.

Ce scénario n’est pas si rare et est source de perte de temps! Le temps est perdu si on arrive à reproduire le bug suite au rejet et que l’on travaille conjointement avec le développeur pour le corriger, le temps est perdu si on n’arrive pas à reproduire la défaillance suite à ce retour.

Comment éviter cette perte de temps ? Comment assurer que la reproductibilité du bug sera plus aisée pour le développeur et même pour le testeur qui a découvert l’anomalie ?

Pour répondre à cette problématique j’essaye toujours de reproduire l’anomalie… mais aussi de la simplifier au maximum.

La reproduction d’anomalie

Détecter une anomalie c’est bien, c’est un des objectifs des tests!

Écrire une fiche d’anomalie simple, claire et avec de nombreuses informations c’est nécessaire!

Néanmoins cela n’est pas toujours suffisant. En effet, reproduire une anomalie est parfois essentiel pour pouvoir la corriger… La complétude de la fiche d’anomalie est censée permettre au développeur de la reproduire… Mais, au final, qui est le mieux passer pour reproduire l’anomalie ? La développeur qui étudie le bug 1 heure ou bien le testeur qui vient de la produire ?

La réponse est évidemment le testeur! C’est pourquoi, lorsque je produis une anomalie, j’essaye tout de suite de la reproduire et applique un processus rituel:

• Tout d’abord je commence par reproduire les étapes qui semblent avoir amenées l’anomalie (quitte à avoir un très grand nombre d’étape). Cela peut être refaire le test depuis le début ou refaire l’enchainement de test.
• Lorsque je réussi à reproduire l’anomalie régulièrement j’ai un scénario en plusieurs étapes (pouvant aller jusqu’à plus de 20 étapes) permettant de le reproduire.
• J’essaye alors de simplifier le scénario en réduisant au maximum le nombre d’étapes. Par exemple, j’élimine les étapes du début, des étapes qui semblent être des étapes « parasites » pour avoir un scénario de reproduction fiable et aussi simple que ce que j’ai trouvé. Attention, cela ne sera peut être pas le scénario le plus court ou simple mais un scénario permettant de reproduire le bug à coup sûr.
• Suite à cela je complète ma fiche d’anomalie en intégrant ce scénario simplifié et en indiquant ce que j’ai compris de l’anomalie, de son comportement.

Ces étapes peuvent paraitre longues et fastidieuses, parfois l’on arrive pas à reproduire l’anomalie mais il faut quand même créer la fiche d’anomalie en espérant que les traces (logs) parleront, néanmoins, en moyenne on gagne énormément de temps sur la correction et la relation avec les développeurs s’en trouve améliorée car il ont plus confiance dans nos anomalies et savent que l’on fait attention à leur envoyer des informations fiables et aussi simples que possible.

Conclusion

Trouver un bug c’est bien. Bien renseigner une fiche d’anomalie c’est indispensable! Il ne faut cependant pas oublier que le but premier, lorsque l’on crée une fiche d’anomalie c’est de pouvoir corriger cette dernière. Et pour cela il faut permettre au développeur d’identifier cette dernière le plus facilement possible. Reproduire une anomalie avant de l’envoyer au développeur est un moyen efficace pour faciliter le travail du développeur et donc corriger la défaillance détectée.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

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

N’hésitez pas à faire vos propres retours d’expérience en commentaire.