On entend beaucoup de choses sur les tests exploratoires, la définition donnée est rarement la même selon les personnes avec qui on discute… Cela va du très compliqué avec l’utilisation de « charter » au simpliste « quelqu’un qui fait n’importe quoi sur l’application ».
Voici celle que j’utilise maintenant :
Les tests exploratoires c’est faire la conception et l’exécution des tests en même temps
Pour rappel, j’avais déjà parlé du cycle de vie d’un cas de test lorsque j’avais travaillé sur le ROI des tests automatisés.
Ce cycle est :
· Design (conception)
· Ecriture
· Exécution
· Analyse (en cas d’échec)
· Maintien
· Archivage
Avec les tests exploratoires on se passe donc de la phase d’écriture (et du maintien) pour faire la première et la troisième phase ensemble.
Pourquoi ces tests ?
Les tests exploratoires ont de nombreux points forts et quelques défauts.
Les défauts sont par exemple:
· 2 Campagnes de tests exploratoires ne sont jamais identiques (même si c’est la même personne qui exécute les campagnes)
· Les tests exploratoires sont très dépendants du testeur
· Les tests exploratoires ne sont pas automatisables
· Il est difficile de capitaliser sur les tests exploratoires (campagnes différentes, pas ou peu d’écriture des cas, archivage compliqué…)
Les points forts quant à eux sont :
· Les tests exploratoires sont une très bonne solution pour éviter le paradoxe des pesticides (car 2 campagnes de tests exploratoires sont toujours différentes)
· Les tests exploratoires sont très peu coûteux si on ne veut faire qu’une seule campagne de test
· Les tests exploratoires sont indispensables pour les tests d’acceptance ou test métiers (voir les niveaux de test)
· Cela permet de tester des scenarii auxquels on n’avait pas pensé
Sur quels projets utilise-t-on ces tests ?
Je dirais que ces tests sont généralement présents à un moment dans tous les projets. Ils ne sont peut-être pas appelés comme cela. Les personnes les exécutants ne pensent peut-être même pas que cela est une activité de test néanmoins cela reste du test.
Je n’ai pas de souvenir de développement d’une application où les développeurs, le chef de projet, les testeurs (tous les intervenants du projet) n’essayent pas d’utiliser l’application (ou le logiciel) afin de se faire une idée sur la qualité de cette dernière ! Faire cela c’est justement faire du test exploratoire et pendant ces tests des fois exécutés pour « s’amuser » de nombreux bugs sont découverts puis reproduit en ré-exécutant le même scénario.
Conclusion
Les tests exploratoires peuvent paraitre complexes et difficile à appréhender. Pour être honnête j’avais également des difficultés jusqu’à il y a peu pour bien expliquer ces tests sans faire de la caricature très simpliste ou une analyse trop technique…
Alors que, finalement, les tests exploratoires c’est juste la partie la plus instinctive du test c’est vérifier la qualité d’une application en l’essayant. Ne pas se borner à un plan déjà fait. Les tests exploratoires c’est laisser place à sa curiosité dans le but de trouver des bugs avant les utilisateurs finaux mais aussi avoir une idée globale de la qualité et du ressenti lors d’une utilisation réaliste de l’application.
Le but des tests étant justement de s’assurer de la qualité d’un produit ces tests me semblent essentiels !
Attention ces tests ne sont que très rarement autosuffisants et comme je l’ai écrit plus haut ils souffrent d’un certain nombre de défauts non négligeables c’est pourquoi il faut de préférences les utiliser en compléments des autres campagnes de test.
N’hésitez pas à rejoindre le groupe Le métier du test.
Merci à Ruslan Desyatnikov pour son article sur les tests exploratoires.
