Je dis dans mon article sur « l’exécution seule » que cette dernière ne sert à rien sans analyse.
Pour rappel l’analyse se fait sur un cas en échec :
Cette analyse a pour but de savoir pourquoi le cas est en échec. Si cet échec est causé par un bug, fournir les informations nécessaires à sa correction.
Les raisons d’un cas en échec peuvent être :
· Un vrai dysfonctionnement de l’application
· Un problème d’environnement (instabilité) ou de données (ex : chercher un vol un dimanche alors que ce dernier n’existe que du lundi au samedi)
· Le test qui est mal écrit et ne vérifie pas ce qui doit être vérifié
· Un test non stable (ex : recherche de la présence d’un mail uniquement en regardant le premier mail de la boite de réception)
· Ce n’est pas un cas que doit couvrir l’application (ex : échec de l’envoi d’un fichier dont le format n’est pas censé être supporté)
Comme vous le voyez, une seule des raisons ci-dessus doit donner lieu à l’ouverture d’un bug. Il est malheureusement très fréquent d’avoir des bugs refusés car « non reproductible ».
Ces bugs refusés car non reproductible le sont souvent à cause d’une instabilité ou de la fiabilité du test (les points 2, 3 et 4). Le développeur et le testeur ont alors perdu du temps avec l’ouverture du bug puis l’analyse du développeur puis le retest du testeur et enfin la clotûre du bug. On voit alors bien l’intérêt de faire cette analyse avant d’ouvrir le bug.
Par contre le bug peut également être refusé par le développeur pour la même raison « non reproductible » alors que l’on a affaire à un vrai bug. Ce cas de figure arrive fréquemment lorsque l’analyse s’arrête après la recherche précédente.
Afin d’aider le développeur à reproduire le bug il faut l’aider, lui donner les conditions que l’on avait lorsque le bug s’est produit. Pour cela il est conseillé de :
· Toujours lié le bug au cas de test en échec avec l’enchainement des actions jusqu’à l’étape en échec.
· Avoir des impressions d’écran si possible
· Donner toutes les informations sur l’environnement (pour une WebApp : quelle url de test, quel navigateur, quel login…)
· Lui fournir les traces si on y a accès
· Tout ce qui permettrait au développeur de reproduire le bug efficacement.
Un développeur ne peut pas (ou je n’en ai pas encore croisé qui le pouvait) corriger un bug (autre que du wording) sans le reproduire.
Si le testeur fait bien toutes ces étapes, le taux de bugs non corrigés diminue tout comme le temps de correction de chaque bug. De plus ce travail en amont permet d’améliorer la relation entre les développeurs et les testeurs. Les testeurs voyant moins de bugs rejetés et les développeurs pouvant travailler plus efficacement sur les bugs reçus.
Le travail d’un testeur lorsqu’un cas est en échec est donc :
· Analyser si le cas en échec est vraiment lié à un bug
· Si le cas est lié à un bug, récupérer et fournir les informations facilitant la correction de ce dernier au développeur.
Ces étapes sont essentielles !
Essentielles pour la bonne entente entre les membres du projet.
Essentielles pour l’efficacité des campagnes de test (meilleure correction de bug, moins de temps perdu)
Essentielles pour que le travail de testeur soit vraiment un métier pas uniquement une tâche automatisable et inintéressante.
Pour rappel, le développeur n’est pas un garagiste !
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.
Une réponse