tests exploratoires vs tests Ad'hoc

Duel: tests exploratoires vs tests ad’hoc

Intro

S’il y a une technique de conception de test que j’apprécie c’est bien les tests exploratoires. Ils sont pour moi une technique de test qui permet de lutter contre le paradoxe des pesticides (usure des tests), découvrir une nouvelle application, multiplier les tests et éviter l’ennui! Malheureusement, ces tests, qui restent très rigoureux, jouissent d’une mauvaise image qui est souvent à l’opposé de la réalité.

Cette mauvaise image est, à mon sens, très liée au test Ad’hoc!

Définitions

Voici les définitions ISTQB de ces 2 techniques de test:

Tests exploratoires:

Une approche du test par laquelle les testeurs conçoivent et exécutent dynamiquement les tests sur la base de leurs connaissances, de l’exploration de l’objet de test et des résultats des tests précédents.

Tests ad’hoc:

Tests informels effectués sans analyse ni conception des tests.

Analyse des définitions

On voit clairement une grosse différence énoncée dans les définitions de l’ISTQB. Les tests exploratoires sont une approche à part entière avec de la conception qui se déroule pendant l’exécution. Les résultats sont utilisés et servent, à minima, à l’orientation des tests de la session.

A titre personnel j’utilise des chartes de test dédiées avec un suivi des tests exécutés et des résultats « remarquables » (bugs ou point d’étonnements)

Les tests ad’hoc, quant à eux, ne sont pas une approche et simplement informels. Il n’y a pas de cadre, pas de suivi, pas d’analyse de risque, pas forcément de capitalisation ou de traces!

Pourquoi cette confusion ?

Je pense qu’il y a plusieurs raisons à cela. En voici quelques unes:

  • Le terme Ad’hoc est très peu connu. Il est donc très peu utilisé. Honnêtement, avant de passer la certification ISTQB, si j’entendais « Ad’hoc » je pensais à du poisson ou à Tintin…
  • Le test exploratoire et le tests Ad’hoc ne se basent pas sur des tests scriptés.
  • Pour beaucoup découvrir une application pendant quelques minutes est vu comme de l’exploration du logiciel. Vu que c’est aussi une sorte de test (qui peut se retrouver au niveau acceptation), cela devient du test exploratoire.
  • Vu de l’extérieur la frontière est mince. Voir un testeur lors d’une session de tests exploratoires peut donner l’impression qu’il ne fait que du clic bouton et agit de manière aléatoire. Si l’on souhaite reproduire ce travail sans comprendre on se retrouve vite à faire du test ad’hoc… Une sorte d’effet Cargo culte.

L’ensemble de ces éléments fait que l’on parle parle généralement de tests exploratoires dès lors où l’on fait une session de tests non scriptés.

Conclusion

La confusion entre tests exploratoires et Ad’hoc est principalement du au fait que les acteurs faisant du test Ad’hoc ne savent pas décrire autrement leur travail que par le terme tests exploratoires.

Les 2 approches peuvent paraitre similaires pour des non initiés et l’absence de connaissance du terme Ad’hoc n’aide pas.

Malheureusement, cette confusion donne une mauvaise image aux tests exploratoires qui deviennent des tests à faible valeur ajoutée (alors que c’est le contraire) où l’on teste un peu au hasard et où il n’est pas possible de savoir ce qui a été testé, comment cela a été testé et pourquoi cela a été testé comme cela.

D’un point de vue plus positif, on peut aussi se dire qu’il y a assez peu de chemin à faire pour que des personnes qui font du test Ad’hoc adoptent l’approche plus structurée des tests exploratoires en mettant en place des chartes remplies pendant les sessions. Lorsque cela est fait, cela apporte énormément de valeur aux équipes de développement qui voient comment le produit est utilisé par une autre personne.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Principe 7 – L’illusion de l’absence d’erreurs

La relation entre la maîtrise d’ouvrage et sa maîtrise d’oeuvre peut rapidement se détériorer si on ne comprend pas la réalité décrite par ce principe. Oui un logiciel peut être est jugé inutilisable à juste titre par la maîtrise d’ouvrage.alors que le logiciel a un fonctionnement validé conforme aux spécifications par

Lire la suite »
7 principes Qualité Agile ?
culture générale

L’esprit d’équipe est la base de la qualité

Description Lorsque l’on pense qualité on pense souvent testeur… Et c’est une erreur! Même si le testeur (ou QA) a un rôle très important il n’est pas le garant de la qualité. D’ailleurs il existe de nombreuses équipes qui délivrent de la qualité sans avoir une personne « étiqueté » testeur. Le

Lire la suite »
Stratégie

Stratégie de test: s’adapter au contexte

Dans mes articles j’ai parlé de beaucoup d’aspects du test comme l’automatisation, des particularités du Scrum, des bonnes pratiques plus récemment d’intégration et de déploiement continu… Tout cela est très bien, malheureusement pas toujours adapté au contexte (ce qui a souvent été remonté dans les commentaires) et dans le test

Lire la suite »