Testez le test exploratoire !

Le test exploratoire, promu au début des années 90 par la Context-Driven School, est devenu un terme rencontré très fréquemment. Cependant, au-delà du buzzword, la méthodologie reste parfois méconnue.
Comment la définir et la mettre en pratique ? Quels en sont les avantages et inconvénients ? Quand l’employer ?

L’image parfois erronée du test exploratoire

Lors du dernier Club Utilisateurs Squash, nous avons présenté des fonctionnalités que nous pourrions ajouter dans la suite Squash (la présentation est disponible ici). Parmi celles-ci, nous avons parlé de supporter la gestion des tests exploratoires : définition de la charte, planification de la session de test, enregistrement de ses résultats et reporting. Les retours ont été très mitigés : quelques personnes présentes avaient l’impression que les tests exploratoires sont un retour aux tests “à la one again” (sic). Mais, non, les tests exploratoires ne sont pas des tests chaotiques, ad hoc ou du simple monkey testing (même si ce dernier fait partie de la boîte à outils du testeur exploratoire). Ce sont des tests structurés qui contribuent à l’amélioration du produit. Ce billet essaie d’expliquer ce que sont les tests exploratoires, comment les organiser et quels sont leurs bénéfices et leurs limites.

Qu’est-ce que le test exploratoire

Le test exploratoire consiste à découvrir le comportement de l’application, à définir les prochains tests à faire en fonction de ce comportement et à les réaliser.

Il y a une boucle permanente entre la découverte de l’application, la conception du test suivant et son exécution :

Un exemple personnel

Je travaillais sur un ERP. Un développeur de l’équipe était en charge de réimplémenter la page permettant de voir les logs de tous les dernier crons (tâches de fond) exécutés, mais je sais que, étant donnée la masse des données, nous avons des risques d’avoir des problèmes de performance. Je décide donc de faire un peu de test exploratoire dessus.

Je découvre la page. Je connais ce qui a été spécifié, une spécification définissant grossièrement la disposition de la page et les informations à y afficher. Je vérifie que la page respecte celle-ci.

Je clique sur un cron dans la liste de gauche. Ses logs s’affichent à droite.

Je me demande ce qui se passe pour un cron qui génère beaucoup de logs. Je sélectionne un tel. Les logs sont bien affichés : scrollbar présente, pas de problème, je peux tout lire.

Mais en scrollant dans la table pour trouver ce cron, j’ai entendu le ventilateur de mon laptop démarrer. Cela m’intrigue. Je vais tester la charge du navigateur. J’affiche le moniteur de ressources Windows et je scrolle la liste. Chrome consomme énormément de CPU, la charge retombe quelques secondes après que j’arrête de scroller.

Je trouve cela suspect. Je vais tester un long défilement. Je fais le test en passant en revue tous les crons de la matinée. Au bout d’une quarantaine de secondes de scroll, JavaScript plante sur un manque mémoire. J’enregistre l’anomalie.

Je reprends le test en analysant le tri, le filtrage… et leurs performances. Je ne trouve pas d’autre problème.

Cet exemple réel est simpliste, les tests conçus sont rapides, la session a été courte (une vingtaine de minutes en tout) et personnelle. Mais cela montre le cycle découverte du comportement → conception du test suivant → exécution de test → découverte du comportement… qui est le principe du test exploratoire.

Comment faire des tests exploratoires

Une méthode fréquemment utilisée pour organiser les tests exploratoires est de faire des sessions.

Définition de la charte

Avant la session, la responsable de l’équipe de tests définit une charte pour la session. Cette charte spécifie :

• l’objectif de la session : une phrase résumant la mission des personnes participant à la session
• la date et le créneau horaire de la session
• les personnes participant
• le périmètre de la session
  - Quelles sont les fonctionnalités et/ou les exigences non fonctionnelles qui doivent être testées ?
  - Est-ce que certains points précis doivent être testés ? Si tel est le cas, les définir sous forme d’une checklist.
  - Est-ce que certains points sont hors périmètre de la session et ne sont donc pas à regarder ?
• la tactique de test : comment répartir les tests entre participants ? Chacun peut jouer une “persona” différente. Chacun peut prendre un workflow d’utilisation différent et étudier ses variations. Certaines équipes utilisent la méthode des six chapeaux…
• l’environnement de test : quelle version du SUT déployée sur quelle instance ? quels navigateurs utiliser ? sur quels systèmes d’exploitation ?…

Il est possible, et souhaitable, d’y ajouter toute information pouvant aider à la conception des tests durant la session : pointeurs vers des sources d’information (doc utilisateur, spécification ou user stories, norme ISO ou RFC…), les anomalies trouvées dans le passé touchant le périmètre de la session, des retours des développeurs qui indiquent que certaines fonctionnalités sont plus risquées…

Exemple de charte

Session de vendredi 17/07 matin 8h-12h30.

Objectif :
Tester l’appli sur différents navigateurs pour vérifier les mécanismes d’internationalisation.

Périmètre :
On va se baser en autre sur les exigences, comme elles sont courtes, je vous les ai recopiées ici.
Pour rappel, les seules locales couramment implémentées sont listées dans l’exigence UI_L10N : Le logiciel doit supporter les locales suivantes : en-US, en-GB, es-ES et fr-FR.

Il faut tester
* les pages hors connexion dont le comportement est défini dans l’exigence UI_I18N_HORS_SESSION : Pour les pages en dehors de session (login, password recovery, credits…), la locale choisie doit être la locale implémentée qui est la plus prioritaire dans la liste priorisée des locales du navigateur. Si la liste du navigateur ne contient aucune locale supportée par l’appli, celle-ci doit utiliser en-US.
* les pages en session dont le comportement est défini dans l’exigence UI_I18N_SESSION : Lorsque l’utilisateur est loggé dans l’application, les textes doivent être dans la locale définie par les préférences de l’utilisateur.

Vous devez vérifier :
* la langue
* le format des montants
* le format des heures
* le format des jours
* le premier jour de la semaine
* la première semaine de l’année

Chacune des locales supportées doit avoir été testée au moins une fois hors et en session.

Libre à vous de vérifier les autres choses dépendantes de la locale ou de la langue. On a récemment corrigé quelques problèmes d’espace avant les ponctuations (anglais vs. français) pour les messages générés dynamiquement, il y en a sans doute encore d’autres à découvrir au passage.

Participants :
Toute l’équipe. Mathilde (la PO) est là en support en cas de question.

Dispatch :
Andrew : Chrome + Firefox en anglais GB et US
Arnold : Chrome + Edge en espagnol
Léa : Safari dans toutes les langues (essaie de vérifier que les changements de locale se passent bien)
Théo : Chrome dans toutes les langues (focus sur les pages admin)
Moi : Chrome + Firefox + Edge en français et anglais GB/US

Environnement de test :
Tests à faire sur l’instance P3 (vérifier que c’est bien la version de fin de sprint 19).
Tester avec Chrome latest, Firefox latest, Edge latest et Safari latest.

Durant la session

La charte a été communiquée aux participants avant la session. Cependant, il est souvent utile que la responsable de l’équipe de test fasse un briefing en début de session afin de s’assurer que tout le monde a bien compris l’objectif de celle-ci et de répondre aux possibles questions. Certaines équipes définissent à ce moment-là la tactique de test (au lieu que ce soit la responsable qui l’ait définie dans la charte).

Il est préférable que l’équipe soit colocalisée dans une même salle, sinon via un tchat, durant la session. De cette façon, chacun peut échanger sur sa progression : “Je pense vérifier que les unités sont bien en impérial sur la version US, est-ce quelqu’un l’a déjà fait ?” “J’ai ce message d’erreur dans la console JS, ça vous dit quelque chose ?”…

Afin de pouvoir exploiter les résultats de la session, chaque participant doit enregistrer au fur et à mesure une description de ce qu’il teste avec le niveau de détail adéquat. Il ne faut pas systématiquement détailler toutes les actions effectuées, sinon le testeur passe la majorité de son temps à écrire ce qu’il teste au lieu de tester. Le but est d’avoir une idée sur ce qui a été testé et ce qui a été laissé de côté. Dans certains cas, le détail précis des actions devra être reporté (par exemple si la tactique de test consiste à balayer un sous-ensemble de la combinatoire des possibilités d’une fonctionnalité, le détail des combinaisons testées devra être reporté).

Lorsque des anomalies sont trouvées, elles sont qualifiées et enregistrées.

Il est conseillé qu’une personne référente des fonctionnalités soit disponible durant la session (par exemple le Product Owner pour les équipes travaillant en Scrum). Il arrive que l’équipe de test constate des choses “bizarres” et ne sache si elles doivent être considérées comme des anomalies. Si une telle personne n’est pas disponible, la question peut être notée dans le rapport de la session pour être posée plus tard par le testeur ou enregistrée dans le système de suivi des anomalies pour les projets qui acceptent de telles pratiques.

Après la session

Après la session, l’équipe peut faire un point pour échanger rapidement et construire une vue d’ensemble de quelles parties du logiciel étaient correctes, lesquelles avaient des problèmes, les types de problèmes trouvés, quelles techniques de test les ont mis à jour, quelles autres techniques auraient pu être utilisées… Cela aidera à la conception des tests lors de la prochaine session.

Il peut arriver que l’équipe pense que la session n’a pas permis de couvrir suffisamment de cas d’utilisation à cause d’un périmètre se révélant trop grand pour la durée allouée, parce que certaines fonctionnalités ont été trouvées défectueuses et mériteraient d’être plus testées… De même, en relisant les notes de la session, la responsable de l’équipe de test peut estimer que certains points n’ont pas été explorés. Si le planning et les priorités le permettent, une seconde session peut être organisée.

Il faudra gérer les questions notées durant la session dès que les personnes capables d’y répondre seront disponibles.

Les notes doivent être archivées. Elles peuvent être utiles pour de futures analyses : ce bug nouvellement reporté est sur un workflow que je pense avoir été testé il y a deux mois, je peux relire les notes pour vérifier et en déduire rapidement qu’il n’était pas sur la version précédente.

Beaucoup d’équipes collectent des métriques (par exemple le nombre de défauts trouvés par heure de test, le nombre de défauts par sévérité…). Celles-ci pourront être utilisées pour apporter une vision de l’efficacité, ou inefficacité, des tests exploratoires au management. Elles peuvent aussi être utilisées pour évaluer l’évolution de la qualité du logiciel, mais ceci est souvent difficile : le nombre de bugs trouvés par heure croît-il parce que la qualité se dégrade, parce que les testeurs sont plus efficaces à trouver les anomalies ou parce que les dernières sessions testaient des fonctionnalités plus risquées ?

Les avantages du test exploratoire

Après une première phase où un testeur qui n’a jamais fait de test exploratoire se sent un peu perdu, j’ai toujours vu les équipes de test très motivées par ce type d’activité : primo, le challenge intellectuel est bien plus grand que de faire un robot-humain qui rejoue pour le n-ième fois le même scénario ; secundo, les testeurs se sentent grandis par le fait qu’on leur fait confiance pour concevoir les tests par eux-mêmes.

Les tests exploratoires permettent de couvrir un éventail de cas d’utilisation beaucoup plus large que dans le cas où on répète à chaque recette les mêmes tests basés sur des scénarios précis.

Les tests exploratoires permettent de se faire une première idée du niveau de qualité d’une nouvelle fonctionnalité avant de lancer l’exécution du plan de test entier. Si le niveau de qualité est trop mauvais, les bugs graves devront être corrigés avant. (Certaines équipes utilisent une notion de “smoke tests” pour le même objectif.)

Les tests exploratoires permettent de tester certains aspects du logiciel sans avoir à payer le coût d’écrire des scénarios manuels ou des tests automatiques. Une situation fréquente (par exemple pour une startup qui parie sur l’avantage d’être la première à occuper le terrain) est qu’une équipe peut manquer de temps pour tester tout ce qu’elle voudrait/devrait de façon structurée, mais elle ne veut malgré tout pas faire l’impasse sur certains points non prioritaires, elle peut tester ceux-ci à moindre coût en utilisant les tests exploratoires.

Sur les grosses applications où certains testeurs se spécialisent sur certaines parties fonctionnelles, les tests exploratoires permettent de garder une vue d’ensemble du produit. Pendant la session, ils ont l’occasion de voir des fonctionnalités qu’ils connaissent moins et les testeurs spécialistes de celles-ci peuvent leur partager un peu de leur expertise.

Pour des équipes qui ont un taux de couverture fonctionnelle très important grâce à leurs tests automatiques, il faut malgré tout toujours que des humains regardent le produit. Les oracles des tests automatiques ne détectent pas tout, par exemple, un texte écrit en blanc sur un fond blanc passera sans doute à travers (parce que le test Selenium vérifie que le texte est affiché, mais pas sa couleur). Les tests exploratoires sont un moyen d’organiser ce regard humain.

Les inconvénients du test exploratoire

Les testeurs doivent être précis dans les rapports d’anomalies. Ils ne peuvent pas se référer à un scénario de test existant. Le workflow d’utilisation doit être suffisamment détaillé pour être reproductible par les autres membres de l’équipe (chef de projet, Product Owner, développeurs, testeurs). L’écriture des rapports d’anomalie prend donc du temps.

Quelle que soit la méthodologie de test, test exploratoire ou autre, les testeurs doivent qualifier chaque anomalie : Dans quels scénarios est-elle présente ? L’impact est-il toujours le même ? Y a-t-il des scénarios fréquents et/ou des impacts graves qui montrent que ce défaut doit être corrigé rapidement ?

Cette qualification des anomalies est particulièrement importante durant les tests exploratoires où il est fréquent que le testeur trouve quelque chose de “bizarre” qui n’est qu’une petite anomalie, puis, en qualifiant/explorant, se rend compte que le problème peut être grave. Cette qualification est donc aussi consommatrice de beaucoup de temps, mais elle est nécessaire pour que l’équipe gère les corrections avec les bons niveaux de priorité.

Les tests menés et, par conséquent, les défauts trouvés dépendent de chaque individu de l’équipe. Selon sa culture, son expérience, sa connaissance du domaine fonctionnel… chacun, et donc l’équipe dans son ensemble, ne fera pas les mêmes tests. Si vous faites une session de test exploratoire avec d’autres personnes, vous n’aurez pas les mêmes résultats. Il n’y a pas de répétabilité.

Il est important que les membres de l’équipe comprennent le mieux possible comment le logiciel testé est exploité par les vrais utilisateurs. Sinon, ils auront moins d’esprit critique sur l’utilisabilité de celui-ci.
Les testeurs expérimentés savent en général mieux et plus rapidement qualifier les anomalies. Ils disposent aussi d’un bagage méthodologique plus important pour imaginer les prochains tests qu’ils vont faire.

Le test exploratoire n’impose pas une liste de scénarios à passer. Il se peut qu’un scénario fonctionnel de base n’est pas été exécuté durant la session. Vous ne pouvez pas donc pas compter que sur les tests exploratoires pour être sûr que le logiciel testé supporte tous les workflows de base requis. Ils ne peuvent pas être l’unique critère pour décider d’une mise en production.

Certains testeurs ont tendance à se focaliser sur les problèmes techniques, ils se laissent prendre par le côté ludique d’arriver à faire planter le logiciel, quitte à y arriver avec des scénarios alambiqués (si j’entre une chaîne de plus de 512 caractères Emoji dans le champ adresse, je génère une ArrayIndexOutOfBoundsException), au lieu de voir de graves problèmes d’ergonomie (en remplissant mon panier sans avoir déjà de compte, puis en créant mon compte au moment du checkout, je me retrouve avec un panier vide). Si vous avez les ressources adéquates, il est plus efficace de détecter les problèmes de validation des entrées utilisateur par du fuzz testing automatisé ou un scan effectué par l’équipe de sécurité. Si ce n’est pas le cas, la validation des entrées utilisateurs peut faire partie du test exploratoire, mais sans tomber dans le syndrome d’y passer la majorité du temps.

Conclusion

Les tests exploratoires ne sont pas une solution miracle. Mais c’est un instrument intéressant dans la boîte à outils méthodologiques d’une équipe de test. Je ne peux que vous encourager à effectuer quelques sessions. Définissez dans quel cadre vous voulez les faire et une première version de process, selon le type de logiciel que vous testez, son cycle de vie (agile ou en V), le panel de tests (manuels et automatiques) que vous avez déjà en place (l’intérêt de retester la même chose en exploratoire est peut-être limité par rapport à combler des manques sur des tests que vous ne faîtes pas), l’expérience des membres de l’équipe… Faites quelques rétrospectives après les sessions pour adapter votre process d’après les retours de votre équipe. Puis, finalement, après plusieurs sessions, décidez si cette technique de test vous semble un bon moyen d’améliorer le travail de l’équipe et si vous la mettez en place définitivement.

Laurent Mazuré
Directeur de projet

En savoir plus sur la gestion des tests :

Test Management | Henix.com