Introduction
Un testeur est amené, dans son quotidien à découvrir des anomalies (c’est normal il les cherche!). Ces anomalies font l’objet d’un processus (workflow) qui les amène régulièrement (ce n’est pas toujours le cas) à être corrigés. Lorsque la correction de ce bug relève d’une modification du code (des fois cela peut être autre chose comme une modification des spécifications) et que cette dernière a été effectuée, la correction de l’anomalie se doit être validée… c’est ce que l’on appelle le retest.
Il semble évident pour beaucoup que le testeur est amené à faire ce retest ce n’est pas malheureusement pas toujours le cas et il arrive que la correction du bug soit validée directement par la personne l’ayant corrigée. Il faut évidemment éviter autant que possible de se retrouver dans cette configuration qui est somme toute assez rare grâce à la place actuelle du test.
L’idée de cet article n’est pas de parler de cette dérive à la marge mais plutôt de parler du « retest » et sa mise en application effective!
La définition ISTQB du retest est: « test qui exécute des cas de test qui ont été en échec la dernière fois qu’ils furent exécutés, de façon à vérifier le succès des actions de correction »
Si on se tient à cette définition il suffit de ré-exécuter un test en échec pour s’assurer qu’une anomalie a été corrigée… ce n’est cependant, de mon point de vue, pas suffisant… et c’est là que l’on arrive à mon « petit truc » de testeur. Le Retest doit, autant que possible, aller plus loin que sa définition!
Le retest étendu, un impératif pour « assurer la qualité »
Le Retest est la ré-exécution d’un test en échec afin de valider la correction d’une anomalie. Malheureusement cette confirmation que le test qui était en échec ne l’ai plus même si elle nous permet de voir que, sur un scénario en particulier, l’anomalie est corrigée cela ne prouve en rien que cette même anomalie est corrigée pour d’autres scénarios… Cela n’éveille t-il pas votre curiosité de testeur ?
De plus la correction du bug a vraisemblablement fait l’objet de modification du code ou de paramètres. Refaire uniquement le test en échec ne permet pas de savoir si cette modification a eu un impact… Il serait dommage que la correction d’un bug en engendre un encore plus important!
Afin d’éviter ces 2 écueils que sont une correction partielle ou une correction « destructrice » il parait essentiel que le « Retest » fasse l’objet d’une attention particulière.
Pour éviter le problème de la correction partielle des tests exploratoires pour tester plus en profondeur le comportement de la fonctionnalité et du scénario correctif. Ces vérifications peuvent d’ailleurs mener à la découverte de bugs proches qui pourraient bénéficier du même correctif (par exemple avec un refactoring) ce qui est, au final, une illustration du principe du regroupement de défauts.
Pour la correction destructrice, l’idée serait de simplement faire une campagne de régression (ou régression allégée basée sur des risques). Le postulat de départ est simple: la correction entraîne une modification, il faut donc s’assurer que cette dernière n’a pas engendrée de régression majeure. J’aime d’ailleurs la conférence de Zoé Thivet sur la notion de bug qui, au final peuvent être considérés comme des développements comme les autres.
Conclusion
Le Retest c’est la vérification qu’une anomalie (ou qu’un bug) est bien corrigé. Cela se fait généralement en ré-exécutant un test en échec (qui l’a souvent détecté) suite à cette anomalie. Malheureusement ce restreindre à cela ne garantit pas une correction complète de l’anomalie ni que cette correction ne soit au final pas plus mauvaise que bénéfique en intégrant des anomalies plus impactantes. Afin de s’assurer de la qualité des correctifs il est essentiel d’aller plus loin dans la validation du bug. Les méthodes sont diverses et variées, comme énoncé j’aime faire un peu de tests exploratoires couplés à une régression (allégée si besoin)… c’est, comme vous l’avez compris, un de mes petits trucs de testeur.
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.
