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 *

Boite du jeu "Bugs End" sur la gestion de la qualité et les tests dans un contexte Agile
Agilité

Présentation de « Bugs End »

L’expérience des 1001 tests Si vous suivez la taverne depuis quelques temps vous avez déjà du tomber sur l’article qui parle des 1001 tests. C’est cette expérience qui nous a poussé, Julien Cahu et moi, à nous relancer dans la création d’un nouveau jeu dédié au test et à la

Lire la suite »