Test exploratoire vs test scripté
Le gain du jour : comprendre la différence entre suivre un scénario écrit à l’avance et explorer une app avec une charte de mission — et savoir quand utiliser chaque approche.
Le test scripté : suivre un plan écrit d’avance
Un test scripté suit des étapes prédéfinies, avec un résultat attendu précis à chaque étape : « 1. Ouvrir l’app. 2. Taper sur Connexion. 3. Saisir un email valide. 4. Vérifier que le bouton Se connecter devient actif. » Il est reproductible, comparable d’une exécution à l’autre, et facilement transformable en test automatisé (leçon 11). C’est l’outil de prédilection pour les tests de régression — vérifier qu’une fonctionnalité qui marchait continue de marcher après un changement de code.
Le test exploratoire : apprendre en testant
Le test exploratoire n’a pas de script figé. Le testeur définit une charte de mission — un objectif et un périmètre, par exemple « explorer le parcours de paiement en cherchant des incohérences d’affichage sur petits écrans » — puis conçoit ses tests au fur et à mesure, en réagissant à ce qu’il observe. Il combine apprentissage du produit, conception du test et exécution en une seule activité.
Le test exploratoire a mauvaise réputation quand il est confondu avec de l’improvisation sans structure. Un bon test exploratoire reste cadré : une charte de mission écrite, un temps limité (souvent une session minutée de 60 à 90 minutes), et des notes prises en continu (ce qui a été testé, ce qui a été trouvé, les questions ouvertes). C’est une discipline, pas un manque de méthode.
Pourquoi combiner les deux
Le test scripté est excellent pour vérifier qu’on n’a rien cassé de connu, mais il ne trouve que ce qu’on a pensé à écrire à l’avance. Le test exploratoire, lui, excelle à trouver des défauts inattendus — des combinaisons d’actions que personne n’a anticipées en écrivant les spécifications. Une stratégie de test mobile solide combine les deux :
- Scripté pour la régression, les parcours critiques (paiement, connexion), et tout ce qui peut être automatisé.
- Exploratoire pour les nouvelles fonctionnalités, l’expérience utilisateur globale, et la recherche de bugs sur le cycle de vie ou les interruptions (appel entrant, rotation d’écran, changement de réseau) — des scénarios trop nombreux pour être tous scriptés.
Une session exploratoire mobile, concrètement
Une charte de mission typique en mobile : « Pendant 60 minutes, explore la fonctionnalité de scan de document en variant les conditions de luminosité, l’angle, et en interrompant le scan par un appel entrant ou une notification. Note toute incohérence d’affichage ou de résultat. » Le testeur documente ses observations au fil de l’eau — souvent directement dans un tableur partagé ou un outil dédié comme TestRail, avec une colonne « observation », une colonne « à re-tester », et une colonne « bug ouvert » reliée au tracker (JIRA).
Vérifie ta compréhension
Une équipe veut vérifier qu'une fonctionnalité de connexion, testée et stable depuis des mois, n'a pas été cassée par un changement de code récent. Quelle approche privilégier ?
Qu'est-ce qui distingue une bonne session de test exploratoire d'un test « au hasard » ?
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.