Définition :
Le paradoxe des pesticides n’est pas exclusif aux tests. En fait il a même été « récupéré » par le test car à l’origine c’est un paradoxe qui nous vient du monde agricole.
Ce paradoxe est assez simple : plus on utilise de pesticides, plus on doit en utiliser car les « mauvaises herbes » deviennent de plus en plus résistante.
On le voit très bien avec les OGM résistants au glyphosate. Le glyphosate est un pesticide très efficace, avoir des plantes résistantes à ce pesticide permet de n’utiliser que ce pesticide et de l’utiliser directement (ce qui tue toutes les autres plantes) dans les champs et donc d’utiliser moins de pesticides et moins souvent.
Cela a particulièrement bien marché… Mais uniquement quelques années. En effet le glyphosate tuant 99.9% des plantes les 0.1% restantes se sont développées et maintenant l’utilisation de pesticides dans les champs OGM résistant au glyphosate est plus importante qu’avant l’introduction de ces plants.
En quoi cela est-il transposable aux tests :
Dans le métier du test, le « pesticide » est la batterie de test, la plante, le logiciel et les mauvaises herbes les « bugs ». Nous favorisons donc en utilisant toujours les mêmes tests des « bugs » résistants à nos tests.
Prenons l’exemple du transfert dans une application mail. Nos tests de régression font un transfert avec PJ et 1 destinataire. Si un bug apparait sur le scénario transfert avec 1 PJ et 2 destinataires alors il n’est pas détecté.
Ce bug non détecté peut rester plusieurs releases et d’autres bugs non « vérifiés » par les tests peuvent également apparaitre. Ce sont les bugs résistants.
Comment éviter cela ?
Il n’y a aucune solution miracle par contre il y a des bonnes pratiques à respecter pour limiter ces impacts.
1- Avoir de bons logs et travailler sur les bugs trouvés par les utilisateurs (dans ce cas une collaboration avec les équipes DevOps est un vrai plus)
2- Lorsqu’un bug (non mineur) est détecté, créer un test dont le but est de le détecter et l’intégrer aux tests de régression. Un bug qui s’est produit a de fortes chances de se reproduire. Ajouter de nouveaux aux différentes campagnes permet de les enrichir et de rendre notre « pesticide » plus efficace.
3- Faire évoluer les campagnes (retirer certains cas, en ajouter d’autres…) afin de s’adapter au logiciel et à ses potentielles faiblesses.
4- Faire des tests exploratoires
Conclusion :
Le paradoxe des pesticides est un phénomène très intéressant. On ne peut malheureusement pas l’éviter mais essayer de limiter son effet. Il nous rappelle également que tout miser sur les tests automatisés n’est malheureusement pas une solution mais surtout que ce qui est important dans un logiciel c’est ses utilisateurs. Il faut les écouter, comprendre ce qu’ils attendent et s’adapter à leurs demandes. Pour cela de bons logs sont nécessaires ainsi qu’une étroite collaboration avec l’équipe DevOps si elle existe.
Voici un schéma récapitulatif:
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
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
