Peut-on trop tester ?
Cette question toute simple pourrait donner lieu à une réponse simple et rapide: oui !
Néanmoins ce « oui » n’a que peu d’intérêts et n’engage que moi s’il n’est pas accompagné pas d’explications. En fait, il a tout autant de légitimité que si j’avais simplement répondu « non ».
Je vous propose donc d’aller un peu plus loin et de voir en quoi cette question a plus de profondeur qu’elle en a l’air.
Que veut dire « trop » tester ?
Avant de pouvoir répondre correctement à la question il faut d’abord tâcher de bien la comprendre. Que veut dire trop tester ?
Cela veut-il dire que l’on teste plus que ce qu’il est possible de tester ?
Le principe des tests exhaustifs impossibles dit bien que non! D’ailleurs ce principe dit explicitement qu’il est impossible de tout tester. En ce sens il ne sera jamais possible de « trop » tester si l’on considère qu’il faudrait théoriquement tout tester.
Cela veut-il dire que le test coûte trop cher par rapport aux autres activités ?
Il est très compliqué de répondre à cela car l’effort de test nécessaire dépend énormément de la complexité du produit et de son environnement, des risques ou encore des obligations légales.
Cela veut-il dire que l’on met trop d’efforts ou de ressources dans le test ?
Si c’est le cas alors il faut aussi se demander si la qualité du service numérique est suffisante. Si cette qualité est insuffisante ou tout juste appropriée, il est dur de dire que l’on teste trop. Par contre on pourrait tester mieux avec une amélioration du processus.
Cela veut-il dire que l’on fait trop de « superflu » (ex: tester sur des navigateurs non utilisés) ?
Si c’est le cas il est en effet important de se poser quelques questions notamment sur la plan de test (souvent appelé stratégie) sur le service numérique.
Cela veut-il dire que l’on a trop de redondances dans nos tests (ex: des tests effectués par les développeurs, les testeurs et le métier) ?
Si c’est le cas alors il faut là encore regarder du côté du plan de test et la rôle de chaque test. Pour cela il y a des modèles bien connus comme le quadrant des tests et les niveaux de test.
Cela veut-il dire que les tests sont goulet d’étranglement (ex: les US sont bloquées en attentes d’être testées) ?
Si c’est le cas, il peut être intéressant de revoir l’outillage ou la répartition des rôles dans la qualité.
Cela veut-il dire que l’on fait de la « surqualité » ?
Si oui, il faut s’assurer de la réalité de cette surqualité et de ses potentiels apports… Si la surqualité est avérée, il sera possible de simplifier le processus de test.
Cela veut-il dire que l’on teste trop une partie du logiciel ?
Cette supposition est celle que j’observe le plus. Répartir l’effort de test n’est pas toujours simple et l’on peut vite se retrouver à tester trop un module ou une fonctionnalité par rapport à un ou une autre. Ce type de déséquilibre s’observe généralement sur des campagnes de régression mais pas seulement! On peut imaginer un déséquilibre avec énormément de tests d’acceptation ce qui ferait tester tardivement certains éléments.
A part la première hypothèse qui est la plus instinctive mais « impossible », tous les autres cas sont potentiellement possibles. Au final « trop tester » principalement à un « excès » de dépenses pour atteindre le résultat souhaité (s’il est atteint).
Comment s’assurer de ne pas « trop » tester ?
On vient de voir qu’il était possible de « trop » tester mais que cet excès ne voulait pas forcément toujours dire la même chose.
Pour s’assurer que l’on ne teste pas trop il est essentiel de bien connaître son contexte… et l’évolution de ce dernier. Il peut arriver que le « trop » d’aujourd’hui soit le « juste » d’hier et potentiellement le « insuffisant » de demain! Les tests dépendent du contexte il est primordial de la faire évoluer avec.
Afin de tester juste, il faut déterminer comment l’ensemble des acteurs qui interviennent sur la création du service numérique travaillent ensemble sur la qualité. On revient ici à la notion de plan de test. Ce plan de test se doit d’être suivi et maintenu. Le maintient et l’évolution doivent se faire de concert (en Agile, les rétrospectives sont un moment propice). Pour s’assurer que les évolutions sont nécessaires ou vont dans le bon sens il est recommandé d’utiliser des indicateurs.
Le suivi des indicateurs (internes: satisfaction de l’équipe, charge de tests, temps passer sur du retravail, % du temps passé sur les exécutions ou la maintenance… ou externes satisfaction des utilisateurs, Nb de bugs majeurs ou critiques en production, Nb de vente ou CA généré…) est souvent une des clés pour mesurer la qualité et l’efficience d’un processus de test.
Conclusion
Il est évidemment possible de « trop tester ». Pour moi, cela revient à dire que l’on ne teste pas assez efficacement et que l’on dépense trop par rapport à ce que l’on attend. C’est principalement une affaire d’efficacité d’un processus qu’il faut sans cesse garder en tête et surveiller.
Sur le papier il est également possible de « trop tester » lorsque le coût des tests dépassent ce que peut rapporter le service (ex: 50 000€ de test pour un chiffre d’affaires du service de 20 000€) dans un cadre commercial. Si le processus de test est relativement efficace, le problème peut être plus profond avec une problématique sur le service numérique qui ne peut être rentable dans son état. Le problème est alors plus profond et peut encore être rattaché au processus avec une amélioration de ce dernier visant à rationaliser le développement des fonctionnalités.
Dans tous les cas, si vous souhaitez montrer la valeur du test il est essentiel de montrer son apport à travers des indicateurs. Les tests et la qualité rapportent gros… Simplement ils ne rapportent pas forcément directement. Il faut mettre en avant des apports tout en gardant à l’esprit qu’il faut constamment s’améliorer.
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
