A partir de quand faut-il faire évoluer ses tests ?

Introduction

Le paradoxe du pesticide est un des 7 principes du test et probablement celui qui a fait l’objet du plus grand nombre d’articles dans la taverne. Cet article met en avant la nécessité de faire évoluer ses tests car ces derniers sont de moins en moins efficaces!

Savoir qu’il faut faire évoluer ses tests c’est bien mais savoir quand le faire c’est mieux! Et ça, il n’y a malheureusement pas de principe du test qui nous explique comment identifier ce moment… ce qui est normal car cela dépend énormément du contexte.

Dans cet article je vais vous proposer des pistes ou des éléments qui peuvent aider dans cette prise de décision d’évolution des tests (ou des campagnes de test). Ces pistes ne sont ni exhaustives, ni immuables et encore moins des règles à suivre obligatoirement. Elles me servent néanmoins dans mon quotidien et sont le résultats de mes expériences.

Exemples d’éléments pouvant amener à faire évoluer ses tests ou ses campagnes

Chacun des éléments proposés aura une « pondération » indiquant une de ses limites

  • Le test ne détecte plus de bugs depuis longtemps (grand nombre d’exécutions) – il faut cependant faire attention à la criticité du test… et bien définir ce qu’est « longtemps »

On part ici du principe que le paradoxe du pesticide a joué et qu’il n’y a que très peu de chances qu’une nouvelle anomalie apparaisse sur ce chemin.

  • La campagne est trop grosse (en terme de temps d’exécution ou de temps de maintenance) – ce n’est pas l’unique solution et cela demande un travail de priorisation important. Par ailleurs ce problème peut être résolu avec des solutions « techniques »

On est ici sur une problématique auxquelles les équipes doivent souvent faire face (surtout en Agile avec l’accroissement du produit!) où l’on peut être amené à faire des « coupes »

  • Les tests ne correspondent plus à l’usage – il faut ici bien définir l’usage et l’utilisation des utilisateurs.

Le produit évolue, son utilisation également. L’important dans une campagne de régression n’est pas de détecter toutes les régressions (c’est d’ailleurs impossible) mais bien de détecter les régressions majeures impactant nos utilisateurs. Une régression sur un chemin qui n’est plus emprunté par les utilisateurs a donc un impact faible

  • Le test ne vérifie plus ce qu’il devait vérifier – pour cela il faut bien identifier le but du test… mais aussi s’assurer qu’au fil du temps il n’a pas également servi à d’autres buts « cachés »

Chaque test est conçu avec un objectif particulier. C’est souvent couvrir un risque sur une utilisation particulière. Le produit évoluant constamment certains tests qui avaient été pensés pour couvrir des cas particuliers peuvent s’avérer ne plus être d’actualités car de nouvelles fonctionnalités couvrent ce cas d’une autre manière. On peut prendre l’exemple d’une taille maximale de PJ envoyée dans un message. Cette limite peut évoluer et alors le test de taille maximale se doit d’évoluer.

  • Le test est « obsolète » – il faut ici bien définir « l’obsolescence » de ce test

Cette obsolescence est généralement dû à une nouvelle fonctionnalité (US) qui en remplace ou en modifie une autre. On est ici assez proche du point précédent

  • Le test n’est plus maintenable – il faut ici essayer d’identifier pourquoi ce n’est plus le cas…

On est ici dans un cas complexe souvent plus lié à de la technique qu’à du fonctionnel. Il faut néanmoins se rendre à l’évidence, un test non maintenable est un test qui devra à terme être supprimé ou retravaillé pour redevenir maintenable

Conclusion

Il n’y a pas de recette miracle permettant de savoir quand l’on doit faire évoluer (ou supprimer) ses tests. Ces décisions nécessaires sont néanmoins délicates et dépendent énormément du contexte. Les éléments proposés dans cet article peuvent être vus comme des indicateurs avec leurs forces et faiblesses. Ils ne sont pas des règles d’or mais peuvent vous aiguiller dans vos choix. Au final c’est votre expérience et votre capacité à bien appréhender et mettre en pratique les différents principes du test qui vous aideront le plus dans votre démarche.

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 *

Agilité

Livre CFTL – Organisation d’une équipe de test

Cet article a été écrit et est paru dans le livre du CFTL « Les tests en agile« . La qualité de la mise en plage est par conséquent nettement meilleur sur le livre. Néanmoins, le contenu reste le même Introduction Qui dit Agilité dit équipes agiles… Et donc équipe pluridisciplinaire. Le

Lire la suite »
Automatisation

Pourquoi automatisons-nous ?

L’automatisation semble nécessaire! On parle toujours plus d’automatisation des tests et plus particulièrement de leur exécution. Les outils d’automatisation de test n’ont jamais été aussi nombreux (ce n’est pas pour rien qu’une majorité des article de la série « Outil de test » traite d’outil d’automatisation). Une conclusion semble donc s’imposer, il

Lire la suite »
Retour d'expérience

Le test, c’est du partage

Récemment, j’ai partagé dans le groupe LinkedIn, le métier du test, l’initiative de Viv Richards sur l’édition d’un livre électronique regroupant 80 histoires de testeurs. Je vous propose de vous partager mon histoire en Français, intitulé dans le livre « Testing is about sharing ». J’espère que mon histoire vous donnera envie

Lire la suite »