Un avis ? Un commentaire ?
Cet espace est pour vous.
Ces illustrations ont été réalisées grâce au projet open-source Historic Tale Construction Kit, version Bayeux. Merci aux personnes qui l’ont créé : Leonard Allain-Launay, Mathieu Thoretton et Maria Cosmina Etegan !
Et non leur absence. Comme le dit l’adage, l’absence de preuve n’est pas la preuve de l’absence…
D’où la nécessité d’une stratégie de test basée sur les risques et d’un ciblage pertinent de l’effort de test.
Il est plus simple, plus rapide et plus économique de corriger une ambiguïté dans une user story ou un cahier des charges, que d’improviser un patch après la découverte d’un bug majeur en pré-production. C’est en ça que le test représente, contrairement à l’idée reçue, un gain de temps pour les équipes. Reste à trouver un moyen de quantifier ce temps gagné pour convaincre les derniers sceptiques !
Après avoir éprouvé vos cas de test une première fois sur l’application, vous pourrez certainement identifier les fonctionnalités les plus « buggantes ». L’effort de test pourra alors être accru sur ces zones. Attention, les bugs peuvent changer de planque au fil du temps, ce qui nous amène au principe suivant…
Remarque du 02/01/2026 : ce principe a changé de nom en 2023 pour devenir « Usure des tests ». C’est, à notre avis, plus compréhensible ainsi !
De même que les insectes développent des résistances contre les pesticides, les cas de tests répétés à l’identique au fil du temps perdent de leur efficacité. Garder un référentiel de tests trop statique tend à laisser les bugs proliférer dans les friches. Il est essentiel de revisiter périodiquement sa combinatoire : le Docteur Lenoir ne se fait pas toujours tuer par le Colonel Moutarde avec un chandelier dans la véranda !
Le contexte métier, le moment de l’année, le nombre et les caractéristiques des utilisateurs constatés au cours des derniers mois… sont autant d’éléments précieux qui permettent d’identifier les types de tests à prévoir.
Ce principe est certainement celui qui en dit le plus long sur le rôle du testeur. L’exigence de qualité nécessite de comprendre en profondeur le besoin des utilisateurs finaux, c’est pourquoi le testeur doit endosser un rôle proactif d’interface entre équipe technique et équipe métier. Sans cela, on aboutira à un produit bien fait, qui ne sera pourtant pas le bon produit.
… si vous passez prochainement votre examen ISTQB Foundation !
Ce n’est pas un bug, c’est un poème
3 maladies de l’automatisation des tests
Le kit de secours métaphorique du testeur agile
Et un supplément de memes inédits ? C’est par ici !
Cet espace est pour vous.