I. Test exploratoire – Ce qu’il n’est pas
Avant d’expliquer ce qu’est un test exploratoire (TE), commençons tout d’abord par expliquer ce qu’il n’est pas ? L’approche du test exploratoire n’est pas à confondre avec le ‘MONKEY Testing’, ce dernier correspond à une pratique consistant à dérouler des scénarios aléatoires sans logique métier particulière ni objectif définit ; cliquer un peu partout pour tester la robustesse du système sans directive ni règle de validation.
Le test exploratoire n’est pas non plus du Ad-hoc testing : Il s’agit là d’une méthodologie de validation non formelle qui s’effectue sans planning ni documentation. La validation est basée sur l’expérience du testeur, sur son historique des erreurs rencontrées ainsi que des cas de tests dérivés de sa bonne connaissance de l’application.
II. Test exploratoire – Ce qu’il est
Le test exploratoire est une façon de valider une application de manière définie et pas complétement aléatoire. Il se base sur la découverte, le bon apprentissage et l’exploration fonctionnelle du « System Under Test ». Il est structuré et enrichi par l’expérience du testeur.
Sans cahier de recette, ni plan de test préalable, le testeur va devoir combiner plusieurs scénarios correspondant à des parcours utilisateurs différents pour aboutir à des test case pertinents, cela lui procurera une meilleure compréhension du système ainsi qu’une meilleure observation de ses limitations.
Revenons un peu à l’importance de l’expérience du testeur : L’explorateur (qui mène les tests exploratoires) doit être autonome et doit bien connaître le volet métier du périmètre adressé, cela lui permettra d’engager une détection sélective des bugs (pas de doublons et donc pas de perte de temps). Il doit également comprendre le produit, analyser et imaginer les endroits sensibles où peuvent se cacher les anomalies. La connaissance du métier du produit est un facteur de succès clé dans l’approche du test exploratoire.
Le testeur peut alors faire la conception et l’exécution en même temps comme défini par Christophe Moustier dans son livre « Le test en mode agile – Edition ENI » >> « Le TE est une démarche qui consiste à réaliser en même temps la conception d’un scénario de test et son exécution en gardant les traces des tests ».
**Résumons ce qu’on a vu ensemble ; les TE sont 😗*
- Des tests non définis (pas de cahier de recette préalable)
- Des tests variés et différents vu le comportement aléatoire
- Des tests liés à des objectifs
- Des tests basés sur une charte qui définit le cadre et les objectifs d’une session de validation
- Des tests basés sur l’expérience des testeurs
On désigne ici par charte la spécification des objectifs du/des test(s) et des idées sur la façon de tester et d’analyser une fonctionnalité, rechercher un problème en particulier ou de vérifier un ensemble de correction de bugs.
III. Pourquoi utiliser les TE et sur quels projets ?
- Tout dépend de ses ressources et du temps consacré aux compagnes de tests, il y’a certaines organisations qui choisissent d’adopter les TE comme méthode complémentaire de test en plus de la méthode scénarisée (en se basant sur des cahiers de recette).
- Les TE peuvent être adoptés également quand le budget et le temps sont limités, cela n’engendre pas de complexité supplémentaire pour préparer la campagne de test.
- Ils peuvent également être adoptés sur des projets où la documentation est faible (peu des spécifications fonctionnelles disponibles) ou qu’elle ne soit pas à jour, avec les TE on peut directement se lancer dans une campagne d’exécution sans perdre de temps et d’effort à la rédaction.
- Pour détecter certains bugs particuliers, mesurer leurs risques et leurs sensibilités, l’équipe QA peut effectuer des TE et définir ainsi des tests scénarisés
- Sur certains projets agiles, les mises en productions sont fréquentes et accélérées, cela engendre une évolution constante des spécifications fonctionnelles (Cahiers des charges, Backlogs…) et des scénarios de test et ouvre la voie à l’adoption de la méthode du « test exploratoire »
IV. Comparaison entre les tests manuels et les tests exploratoires ?
Avant de mettre le focus sur les points de différence, on peut dire que les tests exploratoires sont naturellement des tests manuels, en revanche, nous ne pouvons pas dire que tous les tests manuels ne sont que des tests exploratoires.
V. Phase de préparation et mise en place des TE
Avant de parler de la mise en place des TE, je vais d’abord mettre le focus sur la phase de préparation, une phase importante et nécessaire à la réussite de l’exercice.
Dans de nombreuses organisations agiles, cette phase est habituellement pilotée par le Product Owner (Pilote TE). Elle comporte :
- Un choix des participants : Identifier les QAs capables d’engager l’exercice.
- Le choix du timing : Le temps de la session doit être déterminé, il est généralement entre une demi-journée et deux jours et cela dépend de la complexité du system-under-test (SUT), de l’objectif de la session et de la disponibilité des QA ;
- Création et attribution des chartes : Définir le périmètre métier à explorer pendant la session et l’affecter aux participants, cela génère des « chartes » d’exploration, un exemple de charte basique serait le regroupement des informations suivantes : (fonctionnalité, le nom de testeur, le temps ect….).
- Création d’un tableau de bord qui permet le suivi de la session.
- Mise au point finale : Synchronisation avec les participants avant le démarrage de la session (Partage des chartes, du dashboard…)
La mise en place d’une compagne exploratoire permet de diminuer le temps alloué à la rédaction et la conception des tests et aide à produire des tests mieux ciblés, en revanche, mener un travail exploratoire ne nous soustrait pas à nos obligations habituelles de reporting (bugs, dysfonctionnement…), Le testeur est également invité à adapter la campagne aux anomalies rencontrées en appliquant le principe du regroupement de défauts.
**Pour aider à l’adoption les TE, on peut 😗*
- Les ajouter à nos stratégies de test.
- Prévoir régulièrement du temps pour ces tests exploratoires à travers des sessions dédiées.
- Aligner les objectifs des sessions de TE avec les objectifs et les enjeux QA de l’équipe.
- Garder l’historique et les traces de l’exécution des TE.
VI. Quelles bonnes pratiques peut-on mettre en place ?
- Identifiez les bonnes personnes : Les TE mettent à contribution le sens d’observation des testeurs et leurs connaissance du domaine métier à explorer, choisissez vos champions en fonction de leurs expertises technico-fonctionnelles pour matcher aux périmètres à adresser (Une appétence à la chasse aux bugs et une capacité à identifier les zones à risque contribueront au succès de vos sessions).
- Bien préparez votre session : La phase de préparation est importante, réaliser des tests exploratoires ne signifie pas tester sans contrôle ou de façon aléatoire, cela reste une approche structurée nécessitant de la rigueur et de l’organisation. Les chartes à mettre en place durant la préparation permettront la création d’une classification des bugs et un format de reporting structuré facilitant l’analyse postérieure.
- « Timebox-ez » votre session : Définir des horaires précis pour vos sessions (Heure début & fin) aidera les participants à s’organiser et à prioriser les chemins critiques pour leurs TE
- Précisez et partagez les objectifs de votre campagne : La campagne a-t-elle pour objectif un audit complet ? Doit-elle être focalisée sur une fonctionnalité précise ou plutôt un parcours utilisateur type ? Cela orientera les participants dans la qualification des éventuelles irrégularités et/ou des éventuels dysfonctionnements à rencontrer.
- Faites un bon Reporting: La création d’un rapport détaillé de bugs facilite le travail de débogage des développeurs et leur permet d’avancer rapidement sur l’élaboration de « hotfixes ». Ce reporting permettra également d’alimenter le debrief de session pour voir si des sessions additionnelles seront requises.
- Restez pragmatiques lors de vos explorations : L’amplitude des tests lors d’une session de TE est à modérer de manière pragmatique, un ratissage complet est rarement conseillé, le niveau de profondeur de vos tests dépendra de vos objectifs, certaines campagnes auront pour objectif d’aller à l’essentiel et de se concentrer sur des risques critiques devant être maitrisés, tandis que d’autres s’inscriront dans une logique d’amélioration continue du « system-under-test », en chassant les petits bugs cachés par exemple.
VII. Avantages et Inconvénients associés à l’exploratoire
Mettre en place les tests exploratoires est parmi les pratiques qui me semble importante pour plusieurs raisons :
- Un gain de temps précieux dans la conception des tests
- Peu coûteux à mettre en place
- Détermination des cas de tests pendant l’exécution
- La liberté du testeur : le testeur suit son intuition
- L’exécution d’un plus grand nombre de test
- Avoir des campagnes de test plus pertinentes
- Amélioration des cas de tests futurs
- Détecter des bugs non couverts par d’autres tests
- Un retour rapide sur la qualité du produit
- Focus sur l’expérience plus que sur le processus
Malgré ces avantages, les tests exploratoires présentent quand même des inconvénients :
- Nécessite des testeurs expérimentés et une bonne connaissance du produit.
- Il peut être compliqué de reproduire des bugs
- Pas d’exigence de couverture, certains aspects et/ou bugs peuvent être négligés.
- La pertinence des tests et des résultats dépend de l’expérience des testeurs
VIII. Ce qu'il faut retenir
Les tests exploratoires offrent une nouvelle approche pour se familiariser avec le produit et rendre les tests plus cohérents et performants. Le testeur qui a une bonne connaissance de l’application et qui est généralement autonome pourra libérer son potentiel et s’adonner à ce qu’il maîtrise le mieux pour mieux souligner les parties sensibles de son application. Il faut tout de même garder en tête que les TE ne font pas de manière aléatoire et qu’ils doivent être en complément d’autres tests (Tests automatisés, tests fonctionnels classiques…) pour maximiser la couverture et délivrer un produit de qualité.