Gestion des tests exploratoires

Généralités

Le test exploratoire est une pratique complémentaire des tests classiques. Les tests exploratoires ne sont pas des tests chaotiques, aléatoires, 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, basés sur l’observation et l’expérience plutôt que sur des scénarios de test, qui contribuent à l’amélioration du produit.

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

Ces sessions s'appuient sur des chartes qui indiquent notamment l'objectif et le périmètre des tests.

Un organisateur est en charge de la création, du suivi et de la revue des sessions. Les participants à la session sont quant à eux chargés de l'exécution.

Dans Squash, les chartes de test exploratoires sont gérées dans l'Espace Cas de test tandis que les sessions sont réalisées et revues dans l'Espace Campagnes.

Avant la session

Définir une charte de test exploratoire

La charte de test est définie dans les cas de test au format "Exploratoire" par l'organisateur de la session ou le manager de test.

Les cas de test exploratoires ont les mêmes attributs que les autres formats de cas de test : 'Statut', 'Importance', 'Nature', 'Type', 'Format', 'Description' ainsi que des champs personnalisés.

Ils peuvent également être associés à des exigences.

En revanche, ils ne peuvent être ni variabilisés via des paramètres et jeux de données, ni automatisés.

La caractéristique principale des cas de test exploratoires est la charte de test. Elle est généralement définie par le responsable de l'équipe de test mais un autre acteur peut aussi s'en charger.

Elle comporte deux éléments :

• la charte
• la durée : elle peut également être définie au moment de la planification d'une session dans l'espace Campagnes

Le contenu de la charte peut varier d'une équipe à l'autre mais comporte généralement les éléments suivants :

• L’objectif : une phrase résumant la mission des personnes participant à la session
• Le périmètre :
  • 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 (documentation utilisateur, spécifications ou user stories, normes ISO ou RFC…), anomalies trouvées dans le passé touchant le périmètre de la session, retours des développeurs qui indiquent que certaines fonctionnalités sont plus risquées…

Une charte peut également contenir les éléments suivants :

• La date de la session
• Les personnes participantes
• L'attribution des tests aux personnes participantes (selon la tactique de test définie dans la charte)

Dans Squash, ces éléments sont plutôt à définir au moment de la création d'une session de tests exploratoires dans l'espace Campagnes.

Créer et préparer une session de tests exploratoires

Une fois la charte rédigée, une session de test exploratoire peut être créée par l'organisateur ou le manager de test.

Pour cela, il faut ajouter le cas de test exploratoire au plan d'exécution d'une itération ou d'une suite de tests.
Une fois le cas de test ajouté, le bouton permet d'accéder à la page de consultation de la session.

Cette page donne une vue d'ensemble de la session et permet à la fois de la préparer et de la suivre.

Avant de démarrer la session, l'organisateur doit effectuer les actions suivantes :

1. Définir une date et heure ainsi qu'une durée de session (par défaut, la durée définie au niveau du cas de test est reprise mais elle est modifiable au niveau de la session). Ces deux informations sont à renseigner dans le bloc Informations.

2. Ajouter des exécutions et des participants à la session depuis le bloc Exécutions.
   L'ajout et l'affectation d'exécutions peut se faire de deux manières :

   • Ajout simple en cliquant sur le bouton puis en assignant un utilisateur à l'exécution depuis la cellule correspondante dans le tableau.
     

   • Ajout multiple en cliquant sur le bouton puis en sélectionnant les utlisateurs participant à la session dans la popup. Une exécution est créée et assignée à chaque utilisateur sélectionné.
     

3. Répartir les tests de la session entre les participants selon la tactique définie. Cette action s'effectue dans la colonne "Répartition" du bloc Exécutions.

4. Présenter la session aux participants. L'organisateur peut s'appuyer sur cette page pour présenter la session aux participants en évoquant notamment la charte, la répartition et la durée de la session.

Pendant la session

Exécuter une session de tests exploratoires

Une fois la session présentée aux participants, l'organisateur peut la lancer en cliquant sur [Démarrer la session]. Le statut d'exécution de la session est alors mis à jour à "En cours".

Chaque participant accède à la page d'exécution à laquelle il est assigné depuis le bloc Exécutions d'une session en cliquant sur le bouton .

Depuis cette page, le participant peut :

• consulter les informations générales et les exigences liées au cas de test : bloc Informations et Exigences liées
• renseigner les éventuels champs personnalisés liés à l'exécution : bloc Informations
• consulter la charte de test définie au niveau du cas de test ainsi que la répartition des tests définie au niveau de la session : bloc Charte
• exécuter la session : bloc Notes
• visualiser et associer des anomalies à l'exécution : bloc Anomalies

Contrairement aux autres formats de cas de test dont l'exécution repose sur un scénario prédéfini, l'exécution des tests exploratoires consiste à ajouter des notes au fil de la session dans lesquelles le participant décrit brièvement les étapes réalisées et les comportements observés. Il ne s'agit pas d'écrire des scénarios de test précis mais d'indiquer ce qui a été testé et observé durant la session.

Les tests exploratoires ne s'appuyant pas sur un scénario prédéfini, ils peuvent être sans fin et sont généralement limités dans le temps. Pour cela, un timer permet de suivre le temps écoulé pour l'exécution. Si une durée a été définie pour la session, celle-ci s'affiche à côté du timer. Si la durée définie est dépassée, le participant est averti et peut choisir d'arrêter ou de poursuivre l'exécution.

Pour exécuter un test exploratoire :

1. Lancer le timer via le bouton , l'exécution passe à "En cours".
2. Dans le bloc Notes, ajouter une note en renseignant les champs suivants et confirmer :
   • le type permet de qualifier la note : Commentaire, Suggestion, Anomalie, Question et Point positif
   • un texte riche permet de renseigner les observations et tests effectués et de coller des captures d'écran

3. Une fois la note ajoutée, il est possible de lui associer des pièces jointes et des anomalies.

   Info

   Les notes peuvent être réorganisées par glisser-déposer, modifiées et supprimées. Il est également possible d'ajouter une note sous une note existante via le bouton d'une note.

   Le participant peut mettre en pause l'exécution à tout moment via le bouton . L'exécution est automatiquement mise en pause s'il quitte la page ou ferme la fenêtre.

4. Lorsque l'exécution est terminée, arrêter le timer via le bouton , l'exécution passe au statut "Terminée".

Focus

Selon l'état du timer et le statut d'avancement de l'exécution, certaines actions sont possibles ou bloquées :

• exécution "en cours", timer démarré : tout est possible
• exécution "en cours", timer en pause : la modification, suppression et réorganisation des notes est possible mais l'ajout de note est bloqué
• exécution "terminée", timer arrêté : la réorganisation des notes et l'association d'anomalies aux notes est possible, les autres actions sont bloquées

Suivre une session de tests exploratoires

Durant la session, l'organisateur ou le manager de test peut suivre son déroulement depuis la page de consultation de la session :

• le tableau du bloc Exécutions donne un aperçu de l'avancement et du contenu de chaque exécution :
  • les types et le nombre de notes présentes par type dans l'exécution au survol des icônes
  • le nombre d'anomalies associées à l'exécution
  • le statut d'avancement de l'exécution

• le bloc Activité affiche les notes de l'ensemble des exécutions par ordre antéchronologique. Il est possible de filtrer les notes par utilisateur et/ou par type.

• le tableau du bloc Anomalies connues affiche les anomalies associées à l'ensemble des exécutions de la session

Après la session

À la fin de la session, l'organisateur indique qu'elle est terminée en cliquant sur le bouton [Terminer la session].
La phase de revue et de finalisation de la session peut alors débuter.

Effectuer la revue de la session

La revue de la session est généralement réalisée par l'organisateur ou le manager de test.

Le principe de la revue est de relire les notes de chaque exécution de la session pour vérifier que les différents points abordés dans la charte ont bien été explorés et pour relever les questions afin de les transmettre aux personnes capables d'y répondre.

Pour effectuer la revue :

1. Relire les notes depuis la page de chaque exécution ou depuis le bloc Activité de la session. Pour faciliter la relecture, les notes peuvent être filtrées par type ou par utilisateur.

2. Dans le bloc Revue sur la page de chaque exécution, indiquer que la revue a bien été effectuée :

   • cocher la case "Revue effectuée"
   • ajouter des commentaires si nécessaire

   

   Le statut de revue des exécutions est visible depuis le tableau du bloc Exécutions de la session.

3. Lorsque la revue de chaque exécution est effectuée, la revue de la session est considérée comme terminée.

Finaliser la session

Pour finaliser la session, l'organisateur ou le manager de test doit effectuer les actions suivantes :

• En concertation avec les participants, ajouter des commentaires globaux permettant de faire le bilan de la session dans le bloc Commentaires de la session
• Définir un statut d'exécution global de la session au niveau du champ "Statut d'exécution" du bloc Informations de la session. Ce statut est répercuté au niveau du plan d'exécution et utilisé dans le calcul des indicateurs de couverture des exigences.