Le cycle de vie d’un bug comporte plusieurs étapes décrites ci-dessous :
Dans ce cycle, une étape est malheureusement souvent négligée : La phase de Retest (ou de vérification).
A quoi correspond exactement cette phase ?
La phase de retest d’un bug a plusieurs buts :
· Vérifier que le bug est bien corrigé : un travail est rarement parfait lors de sa première version ! Renvoyé un bug qui n’est pas parfaitement corrigé est très courant dans la vie d’un testeur.
· Vérifier que la correction du bug n’a pas créer de nouveaux bugs plus impactant : Là encore, si on corrige un bug c’est pour améliorer l’application. Il faut donc s’assurer que l’application est mieux après le correctif qu’avant.
Cette étape est donc obligatoire car avant de clôturer un défaut (bug) on doit s’assurer que les deux buts de retest sont bien atteints. On ne peut pas se permettre de considérer un bug comme corrigé si ce n’est pas le cas !
Pourquoi atteindre ces buts est-il essentiel ?
· Un bug peut être mal corrigé. Par là je n’entends pas un mauvais travail de quiconque (bien que cela puisse arriver). Un bug peut être corrigé partiellement. Par exemple sur une application mail un bug peut être : Impossible de transférer un mail contenant une image JPEG. Le bug revient en « retest » et là le testeur s’aperçoit que le bug est bien corrigé lorsque l’on transfert depuis le mail affiché mais pas depuis la liste des mails => Le bug n’est alors que partiellement corrigé (j’aurai pu prendre le même exemple sur une MAJ des spécifications).
· Un bug peut créer de nouveaux bugs ! La correction d’un bug, lorsque ce bug est lié au code peut comme toute modification du code engendrer de nouveaux bugs, des régressions. Si le transfert de mail avec JPEG est corrigé mais que cela a rendu impossible l’envoi de mail sans JPEG alors la correction apportée n’est pas satisfaisante.
Il m’est arrivé quelques fois de ne pas mettre en production la correction d’un bug car cela engendrait d’autres bugs et que cela revenait trop cher de bien le corriger (trop de modifications du code). Dans ce cas certaines équipes décident de corriger ce bug dans une version majeure à venir (cycle en V) ou de créer une US pour le corriger (Scrum). D’autres équipes décident simplement de ne pas corriger le bug.
Que doit-on faire lors cette étape de retest ?
Comme souvent il n’y a pas de formule miracle mais voici mes préconisations.
Afin de vérifier que le bug est corrigé il faut :
· Refaire le scénario exact (ou le plus proche possible) qui a permis de découvrir le bug (même environnement, données, étapes pour le produire)
· Faire des tests exploratoires utilisant cette fonctionnalité afin de vérifier que ce correctif ne fonctionne pas uniquement pour le scénario décrit dans le bug.
Pour s’assurer que le bug corrigé (si c’est un bug corrigé par une modification du cade) n’en a pas engendré de nouveaux plus importants il faut :
· Exécuter les tests de régression (ou au minimum les tests vitaux + des tests de régression sur la fonctionnalité). La correction d’un bug qui engendre une modification du code doit être vue comme l’implémentation d’une fonctionnalité. Comme pour toute fonctionnalité il faut donc, pour valider le bug exécuter les tests de régression.
Conclusion :
La phase de retest est un immanquable du cycle de vie d’un bug. Son exécution rigoureuse permet d’éviter de nombreux désagréments comme, l’annonce de la correction d’un bug alors qu’il ne l’est pas ou l’ajout de bugs plus impactant que celui que l’on a corrigé.
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.
