Démystification des tests exploratoires
Une suite de tests au vert. Une fonctionnalité livrée. Et pourtant, dès la mise en production, un utilisateur déclenche en trois clics un bug que personne n'avait vu venir : un export PDF qui explose dès qu'un libellé contient des caractères spéciaux. Le scénario est familier, et c'est exactement là que les tests exploratoires entrent en jeu.
Ils traînent pourtant une mauvaise réputation. On les imagine comme du test « au feeling », mené sans méthode, faute de temps pour écrire de « vrais » tests. C'est un malentendu. Bien menés, les tests exploratoires sont une démarche structurée, outillée, et redoutablement efficace pour débusquer ce que les tests scriptés laissent passer.
Dans cet article, nous partageons la vision que nous appliquons chez Athoria : la méthodologie Session-Based Test Management (SBTM), les stratégies d'exploration que nous utilisons au quotidien, et les outils qui nous font gagner du temps. Un cas pratique nous accompagnera tout du long de cet article : l'export PDF d'un module de reporting.
Une fausse croyance
Quand on parle de tests exploratoires, beaucoup de QA froncent les sourcils. L'image qui vient est celle d'un testeur qui clique au hasard en espérant tomber sur un bug. Une pratique de second ordre, réservée aux fins de sprint quand il ne reste plus de temps pour bien faire.
La réalité tient en trois mots : objectif, cadre, expertise. Une session exploratoire poursuit un but précis, tient dans un temps limité, et s'appuie sur le jugement du testeur pour flairer les zones à risque et réorienter sa stratégie en direct. Le cliché et la méthode n'ont rien à voir.
Surtout, les deux approches ne s'opposent pas : elles se complètent. Là où les tests automatisés vérifient que le système fait ce qu'on attend, les tests exploratoires découvrent ce à quoi personne n'avait pensé.
une-fausse-croyance.png
Figure 1 : Croyance vs réalité
Définition et principes fondamentaux
Les tests exploratoires sont une approche où conception, exécution et apprentissage se déroulent en même temps. Pas de scénario figé à dérouler pas à pas : le testeur ajuste sa stratégie en temps réel, en fonction de ce qu'il découvre. C'est toute la différence avec un test scripté :
principes-fondamentaux.png
Figure 2 : Workflow du test exploratoire
Cette boucle repose sur trois piliers qui se nourrissent mutuellement.
- L'apprentissage continu : chaque interaction enrichit le modèle mental que le testeur se construit du système, et affûte son flair pour les incohérences.
- La conception adaptative : le prochain test découle du résultat du précédent. C'est-à-dire que si l'export PDF se comporte bizarrement sur un tableau de 2 000 lignes, on creuse là, tout de suite, au lieu de suivre un plan préétabli.
- L'exécution intelligente : le testeur mobilise son expertise métier et technique pour prioriser ses efforts. Cette intelligence contextuelle, aucun test automatisé ne sait la reproduire.
Session-Based Test Management : structurer l'exploration
Comment garder cette liberté sans sombrer dans le chaos ? C'est le rôle du Session-Based Test Management (SBTM). La méthode apporte le cadre sans sacrifier la souplesse qui fait la valeur de l'exploration.
Son unité de base : la session timeboxée, de 60 à 90 minutes. La contrainte de temps force la concentration sur un objectif unique et coupe court à la dispersion. Chaque session s'ouvre sur une charte claire ( = ce qu'on cherche à découvrir ) et se termine par un rapport structuré.
Pendant la session, le testeur alterne exploration et prise de notes. La cible : environ 70 % du temps à explorer, 20 à 30 % à documenter, moins de 10 % au setup et aux blockers. Un repère simple pour équilibrer action et traçabilité :
timing-cible.png
Figure 3 : Répartition cible d'une session de tests exploratoires
Si une session dérive nettement de cette répartition, c'est un signal : l'environnement de test n'est pas suffisamment stable, la documentation effectuée est trop lourde, ou la préparation est insuffisante pour une session fluide.
Quand utiliser les tests exploratoires ?
Dans la pyramide des tests, l'exploration se joue surtout au sommet, au niveau du bout-en-bout. Elle ne remplace ni les tests unitaires ni les tests d'intégration automatisés : elle couvre ce que l'automatisation atteint mal.
pyramide.png
Figure 4 : Un exemple de pyramide de tests
Concrètement, quatre situations appellent une session exploratoire :
| Situation | Pourquoi c'est pertinent | Ce qu'on cherche |
|---|---|---|
| Nouvelle fonctionnalité | Specs incomplètes, cas limites pas encore identifiés | Valider le besoin métier en conditions réelles |
| Refonte majeure | Les tests scriptés peuvent rester au vert en masquant des régressions d'usage | Vérifier que l'expérience reste cohérente |
| Anomalie difficile à reproduire | Un bug intermittent résiste aux approches mécaniques | Isoler les conditions de déclenchement |
| Onboarding | L'exploration active fait monter en compétence plus vite que la documentation seule | Découvrir le produit en profondeur |
Les Testing Tours : des circuits d'exploration
Pour éviter de partir dans tous les sens, on structure la session avec des Testing Tours. Ce sont des parcours thématiques, comme un guide propose différents circuits pour découvrir une ville.
- Le Feature Tour explore une fonctionnalité en profondeur, jusqu'à en devenir expert en une session : sur notre export PDF, cela veut dire tester chaque option (format, orientation, filtres appliqués) et chaque interaction avec le reste du module.
- L'UX Tour adopte le regard de l'utilisateur final et traque l'ergonomie, la cohérence du vocabulaire, les workflows contre-intuitifs (ces problèmes que les tests automatiques ne voient pas).
- Le Performance Tour se concentre sur les temps de réponse à mesure que le jeu de données grossit : l'export d'un rapport de 50 lignes est instantané, mais qu'en est-il à 10 000 lignes ? Ce tour est précieux quand aucune exigence non-fonctionnelle n'a été fixée, pour repérer les latences anormales.
testing-tours.png
Figure 5 : Récapitultatif de 3 testing tours
Les personas : incarner différents utilisateurs
Au-delà des tours, on endosse des archétypes d'utilisateurs pour découvrir des problèmes qui ne surgissent que dans certains contextes d'usage. Quatre postures que nous rejouons souvent :
- L'utilisateur novice, qui découvre l'écran pour la première fois et pose les questions naïves que plus personne ne se pose.
- L'expert, qui enchaîne raccourcis et fonctions avancées.
- Le pressé, qui a une réunion dans deux minutes.
- Le malveillant, qui cherche délibérément à casser le système.
Appliqués à notre export PDF, chacun débusque une classe de problèmes différente.
personas.png
Figure 6 : Exemple de 4 personas
Le Charter : structurer la session sans brider la créativité
Chaque session s'ouvre sur un charter, c'est-à-dire une charte qui oriente sans transformer l'exploration en test scripté.
- L'objectif tient en une phrase et répond à : que veut-on découvrir ?
- La stratégie liste les tours et personas mobilisés.
- Les zones à risque priorisent l'effort.
- Quelques métadonnées contextualisent le tout.
Voici ce que ça donne, rempli, sur notre export PDF :
charter.png
Figure 7 : Screenshot d'un charter sur la feature d'export PDF
Le Session Report : transformer l'exploration en connaissance
À la fin de la session, un rapport structuré rend l'exploration visible pour toute l'équipe. Il documente :
- La couverture : les zones testées et leur profondeur : l'export de 0 à 1 000 lignes creusé à fond
- Les zones non couvertes : l'export au-delà de 1 000 lignes, la gestion des droits, le mode hors ligne : pour planifier les prochaines sessions.
- Les anomalies avec leur criticité et leur taux de reproductibilité.
Voici un exemple pour notre feature d'export PDF :
report.png
Figure 8 : Screenshot d'un report sur la feature d'export PDF
L'outillage : réduire la friction
Pour alléger la charge de documentation, nous nous appuyons sur des outils dédiés comme Xray Exploratory App pour Jira (nouvelle fenêtre). On y crée la session (titre, charter, prérequis) directement dans l'environnement de l'équipe. Pendant l'exploration, le testeur capture screenshots et vidéos sans quitter son flux, et enregistre des notes audio à la volée. En fin de session, un rapport PDF est généré automatiquement et les bugs peuvent être créés dans Jira avec tout le contexte.
xray-exploratory-app
Figure 9 : Parcours animé de Xray Exploratory App
Théorie vs pratique : adapter le SBTM à votre contexte
Le SBTM est une boîte à outils, pas un dogme. Adaptez-le à votre réalité : taille d'équipe, criticité, maturité du produit, contraintes de temps.
Deux éléments sont non négociables :
- Le why : toujours un objectif clair et mesurable, sinon l'exploration perd sa valeur.
- Le timeboxing : toujours une durée maximale : une session de 90 minutes bien cadrée vaut mieux que trois heures qui s'éparpillent.
Le reste s'ajuste. Petite équipe et communication fluide ? Un débrief oral peut remplacer le rapport formel. Application critique ? Augmentez la part de documentation. L'esprit reste le même : structure, focus, capitalisation.
Conclusion : vers une approche équilibrée de la qualité
Les tests exploratoires ne sont ni une baguette magique ni une relique. Bien menés, ils complètent les tests automatisés. Les équipes qui combinent les deux approches obtiennent les meilleurs résultats. Chaque niveau a sa place ; aucun ne remplace les autres.
La clé tient en quatre mots : cadrer, limiter, documenter, partager. À ces conditions, les tests exploratoires deviennent un outil puissant pour débusquer les bugs que personne n'avait anticipés, tout en développant une vraie compréhension du produit et en renforçant l'expertise de l'équipe QA.
Envie d'échanger sur l'intégration des tests exploratoires dans vos projets ? Contacter-nous. (nouvelle fenêtre)