Le test exploratoire : trouver les bugs que personne n’imagine

Imaginez une application de livraison de repas. Le scénario de test disait : ajouter un plat, payer par mobile money, vérifier la confirmation. Tout est passé au vert. Puis une cliente valide son paiement, perd le réseau dans le taxi, rouvre l’application… et paie une seconde fois une commande que le système croyait encore en attente.

Aucun script n’avait prévu ce chemin. C’est le terrain du test exploratoire : on apprend l’application en la testant, et chaque découverte oriente le test suivant. Ce n’est pas « cliquer au hasard ». C’est une méthode, avec une mission, un chronomètre et des notes.

Dans ce guide, vous apprendrez à écrire une charte de test, à mener une session chronométrée, à puiser des idées dans des heuristiques et des « tours » reconnus par la communauté, puis à transformer vos trouvailles en rapports utiles.

Qu’est-ce que le test exploratoire, exactement ?

Le test scénarisé ressemble à une recette suivie à la lettre. Le test exploratoire ressemble au cuisinier qui goûte, ajuste, puis goûte encore. Le tableau ci-dessous compare les deux approches.

Le syllabus de l’ISTQB le juge utile quand les spécifications sont rares ou incomplètes, quand le temps presse, et en complément des techniques plus formelles. Il ajoute qu’il réussit mieux à un testeur expérimenté, qui connaît le domaine et fait preuve de curiosité, de créativité et d’esprit d’analyse. Bonne nouvelle : tout cela s’apprend. Pour situer cette technique parmi les autres, voyez notre carte des types de test.

Comment écrire une bonne charte de test ?

Une charte (test charter) est la mission qui guide une session d’exploration. Elle dit où regarder et pourquoi, sans dicter chaque geste.

Elisabeth Hendrickson, dans son livre Explore It! (2013), a popularisé un modèle en trois parties :

Explorer <la cible>
avec <les ressources>
pour découvrir <l'information recherchée>

La cible est la zone à explorer. Les ressources sont vos leviers : données, outils, conditions, appareils. L’information est ce que vous voulez apprendre. Voici trois chartes pour notre application de livraison :

• Explorer le paiement mobile money avec des coupures réseau et le bouton retour pour découvrir si une commande peut être payée deux fois, ou pas du tout.
• Explorer la saisie d’adresse avec des quartiers sans nom de rue, des repères (« derrière la pharmacie ») et des textes très longs pour découvrir si le livreur reçoit une adresse exploitable.
• Explorer le suivi de commande avec un téléphone de 2 Go de RAM et l’économiseur de batterie activé pour découvrir si le statut reste à jour.

Une charte trop précise devient un cas de test déguisé. Une charte trop large (« explorer l’application pour trouver des bugs ») ne vous dit jamais quand vous avez fini. Visez une zone que vous pouvez couvrir en une à deux heures.

Comment se déroule une session chronométrée ?

En 2000, Jonathan Bach a décrit, avec son frère James, la gestion du test par sessions (Session-Based Test Management). Leur idée : rendre l’exploration mesurable sans l’étouffer. Une session est un bloc de temps sans interruption, consacré à une charte, et qui laisse une trace relisible : la feuille de session.

Dans leur équipe, une session durait environ quatre-vingt-dix minutes ; une session courte, plutôt quarante-cinq ; une longue, près de deux heures. Chaque session se terminait par un débriefing, une courte discussion entre le testeur et son responsable. Le syllabus de l’ISTQB reprend ce schéma : durée limitée, charte, débriefing et feuille de session.

Voici le déroulé que nous conseillons pour une session de 75 minutes :

1. Préparer (5 à 10 minutes). Relisez la charte. Préparez l’appareil, les comptes et les données de test, l’enregistrement d’écran. Activez « Ne pas déranger ».
2. Survoler (10 minutes). Faites un premier passage pour dresser la carte de la zone : écrans, champs, boutons, états.
3. Creuser (40 à 50 minutes). Variez les données, l’ordre, le rythme, les conditions. Suivez les pistes qui sentent le problème.
4. Conclure (10 minutes). Relisez vos notes, isolez les bugs, listez les questions et ce que vous n’avez pas couvert.
5. Débriefer (10 à 15 minutes). Racontez la session à la personne responsable et décidez ensemble des chartes suivantes.

Les Bach demandaient aussi d’estimer la part du temps passée à tester, à enquêter sur les bugs et à préparer la session. Si l’enquête dévore votre temps, la version est peut-être trop instable pour être explorée : un smoke test aurait dû l’arrêter avant.

Et si vous tombez sur un problème grave hors de votre charte ? Suivez-le s’il le mérite : la méthode prévoit ce temps « d’opportunité ». Notez simplement la part qu’il a prise.

Quelles heuristiques et quels « tours » pour trouver des idées ?

Une heuristique est une règle empirique : elle ne garantit rien, mais elle donne souvent une bonne piste. En exploration, elle sert à ne jamais être à court d’idées.

Les tours : visiter l’application comme un touriste

Un tour est une série de tests exploratoires organisée autour d’un thème. La métaphore circulait déjà chez plusieurs auteurs ; Michael Kelly en a publié une liste dès 2005, sous le moyen mnémotechnique FCC CUTS VIDS, et James Whittaker l’a popularisée en 2009 dans Exploratory Software Testing, en rangeant ses tours par « quartiers » d’une ville. Voici des tours de Whittaker appliqués à notre application de livraison :

Les aide-mémoire : SFDIPOT et compagnie

Dans son Heuristic Test Strategy Model, James Bach décrit sept familles d’éléments du produit, résumées par l’acronyme SFDIPOT. Chacune pose une question :

• Structure : de quoi le produit est-il fait (code, services, fichiers) ?
• Fonction : que fait-il (règles métier, calculs, gestion des erreurs) ?
• Données : que traite-t-il (zéro, un, beaucoup ; trop grand ; invalide) ?
• Interfaces : par où y accède-t-on (écrans, API, import, export) ?
• Plateforme : de quoi dépend-il (système, navigateur, mémoire, réseau) ?
• Opérations : comment les gens s’en servent-ils, normalement ou maladroitement ?
• Temps : que se passe-t-il avec les délais, les fuseaux horaires, la lenteur, les actions simultanées ?

Elisabeth Hendrickson propose aussi une « antisèche » d’heuristiques de test en annexe de son livre. Gardez l’une de ces listes ouverte pendant vos sessions : quand l’inspiration baisse, piochez-y une ligne.

Comment prendre des notes pendant l’exploration ?

Une exploration sans notes n’est qu’une promenade. Les notes servent à reproduire les bugs, à montrer ce qui a été couvert et à nourrir le débriefing. La feuille de session des Bach comportait la charte, le testeur, la date et l’heure, la répartition du temps, les fichiers de données, les notes de test, les questions (issues) et les bugs. Voici un modèle prêt à copier :

CHARTE   : Explorer ... avec ... pour découvrir ...
TESTEUR  : ...        DATE : ...        DÉBUT : ...        DURÉE : ... min
APPAREIL : Android 12, 2 Go de RAM, écran 6,5 pouces - réseau 3G instable
DONNÉES  : compte de test n° 2, solde fictif 15 000 FCFA

NOTES (horodatées)
14:12  Paiement normal OK, confirmation en 6 s
14:20  Coupure réseau après le code PIN -> chargement sans fin

BUGS         B1 ...   B2 ...
QUESTIONS    Q1 ...
IDÉES        I1 (prochaine charte) ...
TEMPS        test 60 % / enquête 30 % / préparation 10 % - hors charte 15 %
NON COUVERT  ...

Trois habitudes font la différence :

• Horodatez chaque note : vous retrouverez vite le bon moment dans l’enregistrement d’écran.
• Notez ce que vous n’avez pas testé : c’est aussi précieux que ce que vous avez testé.
• Préfixez vos lignes (B pour bug, Q pour question, I pour idée) : le tri de fin de session prend deux minutes.

À quoi ressemble une session complète sur une application de livraison ?

Le tableau suivant résume la session de 75 minutes, étape par étape.

Bilan : trois bugs, une question, deux nouvelles chartes (le remboursement après un échec, le pourboire). Au débriefing, l’équipe décide de corriger B1 et B2 avant la sortie, et d’ajouter le scénario de coupure réseau à sa liste de régression.

Comment rapporter ce que vous avez trouvé ?

L’exploration ne vaut que si quelqu’un agit ensuite. Trois livrables comptent.

Les rapports de bug. Avant d’écrire, reproduisez : un bug « qui arrive parfois » n’aide personne. Réduisez les étapes au minimum, indiquez la fréquence (« 2 fois sur 3 »), l’appareil, la version, le réseau, et joignez la capture ou la vidéo. Notre guide du rapport de bug efficace détaille chaque champ.

Le débriefing. En dix minutes, répondez à cinq questions : qu’ai-je couvert ? Qu’ai-je trouvé ? Qu’est-ce qui m’a freiné ? Que reste-t-il à explorer ? Quel risque m’inquiète le plus ?

Les tests à garder. Un bug trouvé en exploration mérite souvent un test écrit, voire automatisé, pour qu’il ne revienne jamais. L’exploration découvre ; le script protège.

L’exploration est l’une des compétences qui distinguent un vrai testeur d’un simple exécutant. Si vous voulez en faire une activité rémunérée, lisez comment devenir testeur d’applications, puis rejoignez les testeurs GeekTest.

Pour aller plus loin

• Syllabus ISTQB Foundation Level v4.0.1 (nouvel onglet) : la section 4.4.2 présente le test exploratoire et le test par sessions (en anglais).
• Session-Based Test Management, Jonathan Bach (2000) (nouvel onglet) : l’article fondateur sur les sessions, les feuilles de session et les débriefings (en anglais).
• Heuristic Test Strategy Model, James Bach (nouvel onglet) : le modèle complet, dont les éléments du produit SFDIPOT (en anglais).
• Explore It!, Elisabeth Hendrickson (nouvel onglet) : le livre de référence sur les chartes, avec des extraits gratuits (en anglais).
• Exploratory Software Testing, James Whittaker (nouvel onglet) : le livre qui a popularisé les tours et leurs « quartiers » (en anglais).
• Of Testing Tours and Dashboards, Michael Bolton (2009) (nouvel onglet) : l’histoire des tours avant Whittaker, dont la liste FCC CUTS VIDS de Michael Kelly (en anglais).