Introduction :

Les Tests Exploratoires sont devenus un incontournable des méthodes Agiles pour plusieurs raisons :

• C’est une méthode complémentaires aux Tests classiques, qui ne perturbe donc pas le déroulement d’un ‘Sprint’ ;
• Elle correspond aux principes agiles car elle ne demande pas une spécification lourde des Tests, en cela elle favorise le résultat plus que la spécification ;
• Elle permet de mixer divers méthodes de validation (manuelle, automatique), (fonctionnelle, non fonctionnelle) ;
• Elle met en avant l’humain (Expertise nécessaire) plus que le processus ;
• Elle permet d’augmenter la collaboration entre membres d’un projet (Scrum team) ;
• Elle permet un retour immédiat des problèmes rencontrés (collaboration développement-Qualiticiens).

Dans ce chapitre nous préciserons, tout d’abord, ce que sont les Tests Exploratoires (et ce que ce n’est pas !) ; nous comparerons avec les Tests Manuels classiques ; nous donnerons quelques pistes pour expliquer pourquoi appliquer ce type de validation.

Puis, dans une seconde partie, nous donnerons un exemple de mise en pratique des Tests Exploratoires avec un canevas complet d’organisation. Et enfin nous donnerons les avantages et les inconvénients de cette méthode.

Définitions :

En préambule il est important de préciser que les Tests Exploratoires ne sont pas un « type de tests » mais une façon de valider. Cette notion est importante pour comprendre pourquoi nous devons utiliser cette méthode.

Tests Exploratoires, qu’est-ce que ce n’est pas ?

Il y a souvent confusions entre différentes méthodologies de validation, qui font parties d’un même groupe. Toutes ces méthodes peuvent avoir leur intérêt, dépendant du type d’application sous validation et de la maturité de cette même application et de l’équipe de validation. Nous pouvons citer les méthodes suivantes (liste non exhaustive) :

Monkey Testing :

Les « Monkey Testing » sont une méthode, qui consiste à donner un minimum de consignes aux personnes en charge de la validation. Les idées directrices sont :

• Cliquer partout pour éprouver la robustesse de l’application.
• Eprouver les parties potentiellement sensibles de l’application sans tenir compte de consignes particulières.
• Pas de préparation particulière.
• Pas de consignes ni de scripts

Ad Hoc Testing :

Les « Ad Hoc Testing » sont une autre méthode, qui consiste à effectuer une validation non formelle de l’application. Cette phase de validation serra complètement libre et totalement improvisée.

Error Guessing :

Cette autre méthode consiste à effectuer une validation basée sur les erreurs déjà trouvées dans l’application et est basée sur l’expérience et l’intuition des équipes de validation, cela peut aller de pair avec une écriture de cas de tests.

Il existe d’autres méthodes de validation de même catégorie  (voir chapitre  à définir).

Tests Exploratoires, qu’est-ce que c’est ?

Une session de Tests Exploratoires est une phase de validation qui est organisée pour trouver des failles dans une application donnée. Cette méthode n’a pas pour vocation de remplacer d’autres types ou phases de tests. Elle viendra en complément de Tests Manuels classiques, d’une régression automatisée et de toute autre méthode de validation décrite précédemment (Monkey Testing, Error Guessing, etc.). Cette méthode est formelle et nécessite une organisation en amont et un suivi post session (voir chapitre Organisation). Elle doit correspondre à un besoin et impose des contraintes.

Comme décrit précédemment, les tests exploratoires sont une méthode de validation avec :

• Une phase d’apprentissage pour bien connaitre l’application ;
• Un questionnement sur la gestion des fonctions complexes ;
• Un accroissement itératif de la connaissance de l’application (sessions après sessions et entre les sessions).

Cela repose sur :

• Un Animateur ou Chef d’Orchestre. Celui-ci devra effectuer, en amont, la préparation de la session (en collaboration avec les experts de l’application) ; être le réfèrent durant la phase de validation elle-même ; et s’assurer du suivi de la session, notamment les rapports et la gestion des problèmes trouvés (Voir chapitre Organisation)
• L’expérience du (des) Testeur(s). Ce point et une notion clef des Tests Exploratoires, en effet toute la validation serra basée sur la connaissance et l’expérience des testeurs qui seront à même d’investiguer toutes les parties de l’application et tout spécialement les parties connues comme sensibles. Sans cette expériences les Tests Exploratoires seront peux ou pas efficaces.
• Une préparation allégée. Cette méthode n’est pas basée sur une écriture de scripts contenant l’ensemble des diverses étapes nécessaires à l’exécution d’un flux. Elle est basée sur la création de Chartes (voir chapitre sur les Chartes) permettant une description allégée de ce qui sera à tester, et utilisant l’expérience des participants à la session.
• Une limitation dans le temps. Cette limitation est nécessaire pour une bonne organisation de la session et, notamment, pour le planning de cette session qui serra établi en amont par l’Animateur ou le Chef d’Orchestre.
• Des Chartes. Celles-ci permettront de définir clairement les objectifs et le cadre de la session ainsi que tous les éléments nécessaires à une validation efficace (voir chapitre sur les Chartes).

Les Tests Exploratoires sont clairement définis par les organismes référents des méthodes de tests (ISTQB) et de l’agilité (Agile Alliance), mais aussi Wikipédia (voir chapitre références)

Comparaison avec les Test Manuels Classiques

Même si les Tests Exploratoires n’ont pas pour vocations de remplacer les Tests Manuels classiques (ou les tests automatiques), nous pouvons comparer ces deux types de validation pour mettre en lumière le bénéfice des Tests Exploratoires.

Quand organiser une session de Tests Exploratoires ?

Les Tests Exploratoires sont une méthode de validation qui est relativement lourde à mettre en œuvre donc assez couteuse. Notamment elle demande une préparation assez conséquente (voir chapitre sur l’organisation), elle demande aussi de mobiliser un certain nombre de personnes pendant une durée comprise entre un et deux jours, et demande aussi la présence d’un Animateur et un suivi post session. Pour être le plus efficace possible il est conseillé :

• De n’appliquer cette méthodologie que sur des applications matures, c’est-à-dire que cette méthode n’est pas efficace sur des applications qui viennent de démarrer leur développement ou qui n’ont pas atteint une maturité suffisante pour être relativement stable ;
• De n’appliquer cette méthodologie que si nous avons un groupe d’experts suffisant pour être efficace lors de la session de validation. Sans ce pool d’experts, comme les personnes n’auront pas le niveau de connaissance nécessaire pour être efficace nous conseillons de prévoir d’autre type de validation comme le « Monkey Testing » ;
• D’être sur d’avoir un Animateur ou Chef d’Orchestre pour gérer les différentes phases d’une session de Tests Exploratoires. Sans cet Animateur, il y a un risque de n’avoir pas l’ensemble des phases correctement organisées et donc une perte d’efficacité ;
• D’avoir le soutien du Management. Sans ce soutien, il y a un risque élevé de procéder à une session dégradée, donc moins efficace, et de ne pas avoir une implication complète du groupe de validation durant la session.

Qui inviter pour une session de Tests Exploratoires ?

Comme nous l’avons vu précédemment, une session de Tests Exploratoires nécessite un groupe d’experts. Nous pouvons évidement mixer ce groupe avec des gens plus ‘novices’ qui deviendront les futurs experts ! Il est à noter que les Tests Exploratoires ne sont pas le pré carré des équipes de validation. Pour une session de Tests Exploratoires nous pouvons inviter :

• Les Ingénieurs QA, notamment ceux ayant une grande expérience de l’application ;
• Les Analystes projets, qui ont définis les fonctionnalités de l’application ;
• Des Développeurs qui ont participé à la conception de l’application ;
• Si le Projet est en mode Agile, le Product Owner et le Scrum Master peuvent être invités ;
• Le Chef de projet ;
• Des Représentants des Clients ;
• Des Utilisateurs de l’application ;
• Toute personne ayant une bonne connaissance de l’application.

A noter que pour les personnes susceptibles de participer à une session, une fiche de renseignement peut être crée pour faciliter l’attribution des Chartes (voir chapitre sur les Persona)

Comment organiser une session de Tests Exploratoires ?

Comme nous avons pu le voir précédemment une session de Tests Exploratoires n’est absolument pas improvisée et nécessite une importante préparation. Nous allons proposer un découpage en quatre phases pour organiser une telle session.

Phase 1 : Préparation globale :

Cette phase est dédiée à la préparation des futures sessions de Test Exploratoires. Elle doit être organisée et suivi par l’Animateur et va comporter plusieurs points :

• Une présentation initiale des sessions de Tests Exploratoires. Cette présentation peut être nécessaire si peu de personnes, formant l’équipe globale du projet, ont une connaissance des Tests Exploratoires. Elle consistera à expliquer ce qui va être fait durant les sessions et les avantages de cette méthode ;
• Une définition des Chartes (voir chapitre sur la Charte), c’est-à-dire toutes les informations nécessaires qui devront être présente dans cette Charte. Attention de ne pas donner trop d’information ce qui risque de brider les experts lors de la phase de validation ;
• Une définition des Persona (voir chapitre sur les Persona), qui devront comporter toutes les informations nécessaires à l’attribution des Chartres. Cela devra être fait en collaboration avec les responsables du projet ;
• Une définition du processus et des outils qui permettront la gestion des erreurs lors de la phase de Validation. Ces processus et outils peuvent différer par rapport aux processus classique pour des raisons d’efficacité et de rapidité.

Phase 2 : Préparation de la session

Cette phase va consister à préparer, en amont des Tests Exploratoires, tout le matériel nécessaire à une bonne organisation de cette session. Cette phase est capitale car une mauvaise préparation entrainera une dégradation dans la qualité de la validation, le but étant de se concentrer sur la validation. Cette phase sera gérée par l’Animateur et la personne la plus à même de définir les besoins, le Product Owner est souvent cette personne.  Cette phase comprendra :

• Une sélection des participants à la session, qui seront à ‘piocher’ dans la liste des Persona définis lors de la phase 1 (voir chapitre ‘Qui inviter’) ;
• Une détermination du temps de la session, Habituellement entre ½ journée et 2 jours pour optimiser la session, Cela dépend de la complexité de l’application à tester, de l’objectif attendu et de la disponibilité des participants ;
• Tout l’aspect Matériel, Réservation d’une salle, pour augmenter l’efficacité il est bien d’avoir tous les participants regroupés ; Envoie des mails d’invitation à tous les participants ; Réservation des repas (voir phase 3), etc. ;
• Une création/attribution des Chartes et leur sélection pour cette session. L’idée est de définir ce qui sera validé pendant la session, basé sur la liste des Chartes et de les attribuer aux bonnes personnes, basé sur les Persona. Un planning permettra d’optimiser la session ;
• Une création d’un tableau de bord pour le suivi de la session qui pourra être utilisé pour le rapport. Ce tableau de bord peut être inclus dans votre outil de suivi de tests (Octane, X-Ray, etc.) ou être physique sur un tableau se trouvant dans la salle de la session ;
• Une préparation du rapport final, avec les informations nécessaires, comme la liste de diffusion, les Chartes validées, la liste des participants, etc. ;
• La définition de la version qui sera validé ainsi que la plateforme qui sera utilisée.

Phase 3 : Session de Validation

La session de validation est, évidemment, le point central des Tests Exploratoires. Cette session dépend entièrement de la phase précédente de préparation. Il est très important d’avoir un réel esprit de groupe pour cette session. Pour cela l’Animateur aura un rôle central et devra entrainer avec lui tout le groupe, mais aussi être le garant de la session, notamment s’assurer que tout le monde comprenne bien les Chartes qui lui sont assignées,  de s’assurer que les temps sont respectés, de s’assurer que les problèmes trouvés sont bien enregistrés (avec toute les informations requises). Dans l’esprit d’avoir une réelle communication entre les différents participants il est préférable de réserver uns salle commune.

Proposition de planning pour une session de Tests Exploratoires d’une journée :

• 9h00      Café de bienvenu et accueil des participants.
• 9h30      Introduction par l’Animateur avec explication des objectifs de la journée (une explication des concepts des Tests Exploratoires peut être faite si les participants sont peu au fait de cette méthode).
• 9h50      Distribution des Chartes et explications si nécessaire.
• 10h00   Début de la validation, basée sur les chartes.
• 12h30   Première session de retour (discussion ouverte pouvant déboucher sur de nouvelles Chartes pour la prochaine session).
• 11h40   Repas en commun (pour augmenter la cohésion de l’équipe).
• 13h30   Distribution des Chartes de l’après-midi.
• 15h30   Break
• 15h40   Continuation de la validation
• 17h30   Deuxième session de retour et collecte des informations et problèmes rencontrés
• 18h00   Clôture de la session, un mot du Management peut être la bienvenue.
• 18h15   After Works ? J

Il est à noter que les phases de retour sont très importantes, notamment pour :

• Améliorer l’organisation des prochaines sessions ;
• Créer de nouvelles Chartes si des parties de l’application ce sont montrées plus sensibles qu’attendue ;
• Compléter et mettre à jour les Persona ;
• S’assurer de la bonne remontée des problèmes ;
• S’assurer d’avoir toutes les informations nécessaires pour le rapport final ;
• Augmenter la cohésion des équipes en ayant des échanges directs ;
• Etc.

Phase 4 : Publication des résultats et suivi de la Session

Une telle session n’a de sens que si on communique sur ce qui a été fait et sur les résultats obtenus. Apres la collecte des informations, faite en fin de session, il est nécessaire de fournir un rapport complet sur les résultats. Ce rapport pourrait contenir :

• Le périmètre  global de la validation ;
• La version du produit validé ;
• La liste de fonctionnalités couvertes (basées sur les Chartes) ;
• La liste des participants ;
• La liste de problèmes trouvés ;
• La liste des nouvelles Chartes crées, après passage des Chartes prévues ;
• Le retour des participants.

Les problèmes trouvés devront être suivi jusqu’à leur résolution. D’autre part, basé sur les potentiels enregistrements faits durant la session, la régression pourra être complétée par de nouveaux scripts automatiques.

Durant la rétrospective, un retour de cette session devra être initié par l’Animateur.

Avantages et Inconvénients

Vous pouvez trouver, si dessous, des listes d’avantages et d’inconvénients. Ces listes ne sont pas exhaustives, mais regroupent les points majeurs dont il faut tenir compte.

Avantages :

• Liberté pour le (s) testeur (s)
• Souligne les parties sensibles de l’application
• Aide à trouver des problèmes sur les exigences / spécifications / Guide utilisateur / etc.
• Permet aux testeurs d’augmenter leur engagement
• Gain de temps dans la conception des tests
• Concentration  sur l’expérience plus que sur le processus
• Croissance itérative de la connaissance du produit
• En accord avec les méthodologies agiles, utilisable dans d’autres méthodologies
• Utilisable pour les tests non fonctionnels: utilisabilité, performance, etc.

Inconvénients :

• Requiert des testeurs expérimentés
• Nécessite une bonne connaissance du produit pour la conception initiale
• Difficulté à suivre les progrès de la campagne de tests
• Peu ou pas de couverture des besoins
• Difficulté d’automatiser les tests
• Scénarios de défaut non évident à fournir
• La charte de validation doit être clairement définie

Charte

La Charte est un élément très important des sessions de Tests Exploratoires. C’est avec les Chartes que l’Animateur, en collaboration avec les experts, va proposer les différentes parties à tester de l’application.  Ces Chartes permettent aussi de rassurer le management sur la valeur d’une telle session car elle donne un coté maitrisé et officiel !

Pour définir Les chartes nous pouvons nous baser sur plusieurs éléments :

• La connaissance des Ingénieur Qualité qui connaissent les parties sensibles;
• Les doutes et connaissances du Product Owner;
• Les développeurs qui peuvent définir les zones de codes sensibles;
• Les informations remontant des « daily meetings » ;
• Les retours clients;
• Les retours des utilisateurs;
• Les retours de la phase de « Component Testing » ;
• Les précédentes sessions de Tests Exploratoires ;
• Etc.

Ces Chartes peuvent être des documents Word ou Excel mais peuvent aussi faire partie d’un référent de tests plus élaboré comme Octane ou X-Ray. Les différentes parties devront être définies dans la Phase 1 de l’organisation de la session. Vous pouvez trouver, si dessous, un exemple de Charte :

Exemple 1 (Charte)

Persona

La notion de Persona est issue du monde du Marketing, et n’est donc pas typique de la validation ni des Tests Exploratoires. Elle a deux objectifs :

• Rendre la phase de Tests Exploratoires plus attrayante pour les participants (gamification) ;
• Connaitre les compétences des participants pour mieux attribuer les Chartes et rendre la session le plus efficace possible.

Les Persona peuvent être très classiques, telles celles utilisées par le marketing (voir exemple ci-dessous), mais rien ne vous empêche de définir des profils plus ‘ludiques’.

Exemple 2 (Persona Classique)

Les Persona peuvent aussi être définis par des caractères. Par exemple donner des rôles à chacun comme :

• Le neutre, qui se focalise sur les fonctionnalités définies en amont ;
• Le négatif, qui va chercher les failles partout dans l’application ;
• Le positif, qui va valider le fonctionnement global de l’application sans chercher fatalement les erreurs ;
• L’émotionnel, qui utilise son ressenti pour aller débusquer les problèmes ;
• Le créatif, qui va imaginer des scenarios à la limite.

Ces rôles peuvent être inversés durant la session de tests.

Références

• ISTQB : http://glossary.istqb.org/search/exploratory%20testing
• Agile Alliance :  https://www.agilealliance.org/glossary/exploratory-testing/#q=~(infinite~false~filters~(postType~(~’page~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’exploratory*20testing))~searchTerm~’~sort~false~sortDirection~’asc~page~1)
• Wikipédia :  https://en.wikipedia.org/wiki/Exploratory_testing