Les 7 principes du test: le paradoxe du pesticide (5/7)

Dans cette série vous pourrez trouver dans chaque article une présentation d’une des 7 principes fondamentaux du test.

Paradoxe du pesticide

Description

Ce principe est probablement un des principes les plus complexe à comprendre au premier abord. C’est pourquoi c’est le seul principe qui a déjà eu le droit à un article explicatif dédié ainsi qu’à un article l’illustrant.

Son énoncé est assez simple: plus on exécute un test moins il sera efficace et pertinent pour trouver des anomalies. Le nom de paradoxe des pesticides vient de l’agriculture où des pesticides au début particulièrement efficaces le deviennent de moins en moins au fur et à mesure du temps. Le glyphosate en est d’ailleurs un bon exemple.

Quand on prend le temps de se pencher (et que l’on repense à son origine) sur ce paradoxe il devient somme toute assez logique. Je ne reviendrai pas aujourd’hui sur l’analogie avec les champignons qui ne se trouvent pas sur les sentiers ou celle avec les pesticides mais vous propose de continuer avec la pêche. A force de pêcher tous les jours avec le même filet (attrape les poissons à partir d’une certaine taille) au même endroit on se retrouve à attraper de moins en moins de poissons. La raison est simple:

  • dans la zone seul les poissons plus petit ou passant « au dessus » ou « en dessous » du filets subsistent et n’ont pas de raisons d’être attrapés
  • hors de la zone tous les poissons vivent tranquillement leur vie de poisson

C’est exactement le cas avec les tests et les bugs. Un test ne détectant pas un bug à un instant T ne le détectera pas à un instant T+1.

Conséquences

La principale conséquence de ce paradoxe c’est que l’on peut avoir des applications très bien testé au départ et faisant l’objet d’un suivi sérieux avec des campagne de test régulière tout en ayant une application truffée de bugs et de mauvaise qualité, rendant évidemment l’efficience des tests très faible.

Les réponses à ces conséquences sont nombreuses et souvent complémentaires. En voici 2 fréquentes:

  • La gestion de campagnes de régressions « vivantes » et qui doivent évoluer régulièrement. Il peut être conseillé de faire un suivi de ses tests de régressions et de repérer ceux qui ne repèrent pas de bug depuis un certains temps. Ces cas identifiés peuvent alors faire l’objet d’une réflexion afin de savoir s’il peut être pertinent de faire évoluer leur données, leur parcours, voire même de les supprimer de la campagne pour en mettre de nouveaux.
  • La mise en place de campagnes de tests exploratoires qui sont également très intéressantes à mettre en place pour lutter contre ce paradoxe.

Ce qu’il faut retenir

Le paradoxe des pesticides nous rappelle que les tests dépendent du contexte. Des tests pertinents un jour ne le sont pas forcément le lendemain car le contexte évolue. Le contexte évolue d’ailleurs simplement avec l’exécution des tests car un test n’ayant pas relevé d’anomalie 1 jour n’en révélera vraisemblablement pas le lendemain s’il n’y a pas de changement. Le test pertinent le jour J devenant non pertinent le lendemain.

De manière générale le paradoxe des pesticides commence à se ressentir après de nombreux changements applicatifs et de nombreuses exécutions. De part la construction incrémentale des méthodes agiles, le paradoxe des pesticides est un sujet qui sera/est de plus en plus visible il faut donc apprendre à lutter contre en faisant vivre ses tests.

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.

Publié par

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s