Remerciements préalables
EDIT (paragraphe ajouté le 20 septembre 2018)
Ces illustrations ont été réalisées grâce au réjouissant projet open-source Historic Tale Construction Kit, version Bayeux. Merci à leurs concepteurs Leonard Allain-Launay, Mathieu Thoretton et Maria Cosmina Etegan !
Dans notre enthousiasme nous avions omis de les citer dans la première mouture de cet article, datée du 14 septembre 2018. Merci à l’un de nos lecteurs de nous avoir signalé cet impardonnable oubli !
Les tests montrent la présence de défauts
Et non leur absence. Comme le dit l’adage, l’absence de preuve n’est pas la preuve de l’absence…
Les tests exhaustifs sont impossibles
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.
Tester tôt
Il est plus simple, plus rapide et plus économique de corriger une ambiguité 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 !
Le regroupement des défauts
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…
Le paradoxe du pesticide
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 !
Les tests dépendent du contexte
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.
L’illusion de l’absence d’erreur
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.
Bonne chance
… si vous passez prochainement votre examen ISTQB Foundation !
Vous pouvez librement utiliser ces images en citant Hightest et en indiquant un lien vers notre blog.
Vous reprendrez bien un peu d’humour testeur 🙂
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 !