Ces principes font partie intégrante du métier du test et sont généralement appliqués sans le savoir. Ils sont néanmoins une bonne base de réflexion et n’en avais pas encore parlé dans mes articles. Afin de les illustrer je reviendrai certaines fois sur ma métaphore entre les tests et la chasse aux champignons !
Les tests montrent la présence de défaut
- Si on reprend la métaphore de la chasse aux champignons cela revient à dire que ce n’est pas parce que nous n’avons pas trouvé de champignons qu’il n’y en a pas!
- Les tests vont vérifier certains scénarios. Ils peuvent uniquement montrer si des anomalies sont présentes sur ces scénarios spécifiques. Je dirai même plus en ajoutant que sur les scénarios exécutés, seules les vérifications demandées par les tests sont couvertes.
Les tests exhaustifs sont impossibles
- Impossible de vérifier chaque cm² d’une forêt
- J’ai écrit un article qui tente de pousser le concept de couverture exhaustive qui revient sur le problème. Dans les faits, dès lors où l’on peut faire autant d’étapes que l’on veut sur un logiciel, alors les scénarios possibles sont infinis. Il y a également des limites quand les variables se multiplient car le cap du million de possibilités est très vite franchi.
Tester tôt
- Corriger une erreur dans les spécifications coûte moins que la corriger après son développement. En effet là où, dans le premier cas l’ajout d’une phrase suffit à sa correction, pour corriger dans le deuxième cas il faut investiguer, corriger puis vérifier les éventuelles impacts du correctif sur l’application avec des tests de régression.
- De plus, une anomalie majeure trouvée en production peut tuer une application
- C’est le principe de base du shift left !
Regroupement de défauts
- Les champignons se trouvent souvent par « groupe ». Lorsque l’on en trouve un alors il y a de fortes chances d’en trouver d’autres à proximité.
- La majorité des anomalies vient d’un petit nombre de modules. Chaque application a ses faiblesses, la majorité des anomalies sera trouvée au niveau de ces faiblesses. Si je trouve une anomalie sur le transfert d’un type de fichiers avec mon application mail, il y a des chances qu’il y ait des problèmes sur d’autres types de fichiers
Le paradoxe du pesticide / L’usure des tests
- A force de toujours chercher au même endroit, il n’y a plus rien à cet endroit et les autres bugs ne sont pas détectés. C’est exactement le même cas pour les champignons. Si vous souhaitez en savoir plus sur ce paradoxe, je vous invite à lire mon article à ce sujet.Voici un schéma qui illustre ce paradoxe :
Les tests dépendent du contexte
- Selon la saison et la météo on ne cherche pas les mêmes champignons!
- Le niveau d’exigence de sécurité n’est pas le même pour des communications entre chefs d’Etats que pour des communications entre citoyens lambda.
L’illusion d’absence d’erreurs
- Si le produit est mal conçu, trouver et corriger des bugs ne sert à rien
- Cela illustre la différence entre spécifications et utilisation
Conclusion :
Comme on le voit, tous ces principes du test relèvent du bon sens. Il semble évident de ne pas pouvoir tout savoir, que l’on ne peut pas affirmer qu’il n’y a pas de défaut sur ce que l’on a pas validé, que trouver tôt un défaut coûte moins cher car il y a moins de dépendances…
Ce n’est cependant pas parce que ces principes semblent évidents qu’ils sont toujours suivis. Il est toujours bon de s’en rappeler afin d’éviter de tomber dans certains travers.
Si ces principes vous intéressent et que vous voulez en savoir plus, je ne peux que vous conseiller de voir les vidéos d’Anir Radid à ce sujet présentes dans La taverne du testeur.
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
2 réponses