« Retour

Les 7 principes généraux du test en illustrations

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...

Un testeur se faisant questionner par une équipe produit, et résistant à leur besoin d'entendre qu'il n'y a aucun bug dans l'application.

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.

Un testeur tentant vainement d'atteindre les cimes de l'exhaustivité.

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 !

Il vaut mieux corriger un petit bug aujourd'hui qu'un gros bug demain.

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...

Un testeur, cherchant en vain une colonie de bugs, qui se calfeutre à son insu dans une masure?

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 ! 

Testeurs cherchant en vain des bugs là où, à force d'être traqués, ils ne s'aventurent plus.

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.

Il ne faut pas tester la voile si le bateau est sur la plage.

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.

Qui construit un arc parfait doit s'assurer que son client n'attend pas une harpe.

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 d'ISTQB !

Performance, charge, stress... quelle différence ?

Un avis ? Un commentaire ?

Cet espace est pour vous.



2 commentaire(s)

  • Good basics to start with...

  • Bonjour, Il serait un minimum professionnel de citer la source vous ayant permis de réaliser vos visuels. http://htck.github.io/bayeux/#!/ Merci.