La taverne du testeur

Petits trucs de testeur: le retest

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

test

Rendre plus visible le travail des testeurs

Introduction: la visibilité un point clé Le métier de testeur est un métier d’échange, de communication d’analyse et de réflexion. Ce métier est un métier de plus en plus mis en lumière et valorisé. Néanmoins il reste encore mal connu et, au final, certaines personnes le voient encore comme une

Lire la suite »
conférence

Test Bash Home : une réussite internationale

Vous connaissez surement le Ministry of testing, qui regroupe la plus large communauté de testeurs à travers le monde. Et chaque année, plusieurs événements tests, appelés Test Bash, ont lieu un peu partout dans le monde. Comme vous le savez, un certain virus a décidé de faire de cette année

Lire la suite »
Crowdtesting

J’ai testé le CrowdTesting (côté testeur) !

Attention: cet article a été écrit en 2017. Vous trouverez à la fin de ce dernier des réponses par rapport à des problèmes rencontrés (évolution ou explication) lors de mon expérience. PS: les images proposées ne sont plus les images initiales mais sont validées par Applause car permettent de ne

Lire la suite »