Le Test déroulé par des experts du métier : Comment organiser une session de Tests Exploratoires ?

Testing | 18 septembre 2024

Banniere de notre article sur les tests exploratoires. Photo de Guillaume avec citation de l'article

Si l’on en croit la définition dans le glossaire de l’ISTQB, les tests exploratoires sont une approche des tests par laquelle les testeurs conçoivent et exécutent dynamiquement des tests en fonction de leurs connaissances, de l’exploration de l’élément testé et des résultats des tests précédents.

Autrement dit, il s’agit d’une session de test très utilisée en méthode agile pour évaluer la qualité des logiciels.

Ils sont particulièrement utiles lorsque :

  • Les spécifications sont manquantes, obsolètes ou inadéquates,
  • L’on fait face à des contraintes de temps importantes pour les tests : livraison prévue en production prochainement ou correctif urgent d’un bug en production,
  • L’on souhaite compléter d’autres techniques de test plus formelles.

Ces tests exploratoires font partie des techniques de test basées sur l’expérience, tout comme l’estimation d’erreur ou les tests basés sur les checklists. Les cas de test sont basés sur l’expérience, l’intuition et les compétences du testeur ou du spécialiste métier. L’efficacité de ces tests est directement proportionnelle à cette expérience.

Les tests exploratoires : la séance type

Découvrez un aperçu du déroulement typique d’une séance de tests exploratoires, mettant en lumière les intervenants clés et les étapes cruciales pour réussir efficacement ces séances.

Prenons comme exemple le changement du logiciel de la ligne de caisses d’un hypermarché.

Le Testeur ne sera pas forcément le testeur…

Qui serait le ou la plus susceptible de trouver des bugs pertinents, bloquants au premier regard ? Un testeur junior fraîchement sorti de formation ? Un testeur expérimenté ? Un(e) employé(e) de l’hypermarché qui travaille en caisse depuis plusieurs années ?

Évidemment, c’est l’expert métier qui passe ses journées sur la caisse qui sera le plus expérimenté pour tester le nouveau logiciel. Il ou elle pourra facilement trouver des bugs bloquants nécessitant une correction urgente ou identifier un trou dans la raquette des spécifications.

Quand intervient le sachant ?

Ça y est, nous avons identifié nos experts, nos sachants, nous pouvons donc démarrer la session de test exploratoire. Il ne reste qu’à les faire venir sur le site de développement du logiciel et de préférence 1 ou 2 sprints avant la mise en production, car le logiciel est dans un état suffisamment avancé pour être testable par les utilisateurs finaux et surtout pour avoir le temps de corriger les bugs qui seront découverts.

Une session de test exploratoire dure en général une demi-journée. Chaque scénario sera traité par plage de 20 – 30 minutes.

Les Intervenants présents lors de cette séance :

Les sachants, experts du domaine et représentants du métier : des spécialistes possédant une connaissance approfondie du logiciel et de ses utilisateurs finaux. Leur expérience et leurs intuitions guident l’exploration du logiciel de manière efficace et ciblée. Dans notre exemple, nous allons demander à 5 ou 6 caissiers ou caissières de tester notre logiciel.

Les Observateurs : les développeurs, les testeurs, le Test Leader, le Product Owner, ou toute autre partie-prenante pertinente. Ces observateurs assistent à la séance pour guider les employés du magasin, car ce ne sont pas des testeurs de logiciel professionnels. Le but étant de laisser les sachants expérimenter le logiciel en autonomie et d’avoir à portée de main ceux qui l’ont conçu, développé et testé pour les aider à la résolution des problèmes qui pourraient être identifiés.

Déroulement de la Séance :

  • Préparation :

Avant le début de la séance, le PO et le Test Leader expliquent aux parties prenantes le contexte, les fonctionnalités à explorer, le contenu de la prochaine livraison, ils identifient les scenarii et les zones à risques. Ils peuvent également définir des objectifs spécifiques pour la séance, en rappelant la date de mise en production prévue.

  • Exploration Initiale :

La séance débute par une exploration initiale du logiciel, où les experts du domaine (les employés de la caisse) naviguent à travers différentes parties de l’application sans suivre de plan de test préétabli. Cette phase permet de se familiariser avec le comportement général du logiciel et de simuler le comportement des utilisateurs.

  • Identification des Scénarios et Exploration approfondie simultanée :

En se basant sur leurs connaissances du métier, les experts identifient des scénarii de test pertinent à explorer plus en profondeur. Dans notre exemple, il sera peut-être pertinent d’envisager de tester avec différents moyens de paiement (diverses cartes bancaires, chèque, espèce, chèques-cadeaux, Tickets restaurant…).

Les tests peuvent inclure des cas d’utilisation critiques, des fonctionnalités récemment développées ou des zones à haut risque, car l’application ou le logiciel peut être déjà existant en environnement de production.

Le résultat des tests précédents influence la création de nouveaux cas de test. Dans notre exemple, si le test du paiement par tickets restaurant version papier ne fonctionne pas, cela incitera sûrement les sachants à essayer avec des tickets restaurants version carte électronique et explorer si le bug constaté ne se limite qu’à un périmètre ou s’il est généralisé. Alors que si la version papier avait fonctionné directement, les employés du magasin n’auraient pas forcément eu l’idée de vérifier la version électronique.

  • Documentation des Résultats :

Pendant la séance, il est important de documenter soigneusement les défauts détectés, en fournissant des descriptions détaillées, des captures d’écran et des étapes de reproduction. En effet, ce sont les sachants qui déroulent les cas de test, mais les observateurs sont avec eux dans la pièce. Ils peuvent prendre des notes sur les remarques, sur les fonctionnalités manquantes, apporter des éléments de réponse tels que :

  • « Si tu veux faire un remboursement sur la carte bancaire, il faut que tu cliques là. »
  • « Cette fonctionnalité (paiement par virement) n’a pas encore été développée, mais nous notons le besoin pour l’intégrer au Product Backlog. »
  • « Cette option a été écartée lors d’une précédente réunion. »

Pour faciliter la reproductibilité des bugs et faciliter la correction par les développeurs, il est recommandé d’enregistrer les écrans des testeurs, permettant ainsi de capturer précisément les actions effectuées et les problèmes rencontrés. Les sachants sont des experts métiers, mais ils n’ont pas pour habitude de créer des fiches d’anomalie complètes et la correction des bugs est beaucoup plus simple si la reproductibilité est garantie.

  • Feedbacks et commentaires :

À la fin de la séance, les observateurs participent à une révision des résultats, discutant des défauts détectés, de leur gravité et des actions correctives nécessaires. Cette discussion permet d’envisager avec le Product Owner, quelles seront les priorités à considérer lors de la prochaine itération.

Le fait de participer à des sessions de tests exploratoires permet régulièrement aux experts métier de comprendre les tâches de développement et de test et inversement, l’équipe de développement peut avoir un regard neuf sur l’importance de certaines fonctionnalités qui ne paraissaient pas si importantes que ça avant les tests.

Les tests exploratoires permettent d’obtenir l’adhésion de la nouvelle version du logiciel par les sachants qui pourront être les ambassadeurs de la nouvelle version. Si au moment de la mise en production, une fonctionnalité a été améliorée ou un bug corrigé à l’initiative de l’un des sachants, il sera fier de le montrer à ses collègues en leur disant : « T’as vu, si ça marche, c’est grâce à moi. Ils ont corrigé mon bug ! »

Conclusion

En résumé, les tests exploratoires sont un très bon moyen de détecter des problèmes qui seront importants pour les utilisateurs finaux. Ils ne remplacent pas les techniques de tests classiques (Tests boîte noire, Tests boîte blanche) mais viennent les compléter, surtout si les délais sont courts ou si la documentation est incomplète ou indisponible.

Leur réussite dépend du niveau d’expérience et de la disponibilité des experts qui y participent. De plus, les tests exploratoires favorisent l’adhésion des équipes qui y ont participé. En impliquant activement les experts du domaine et d’autres parties prenantes, ces tests encouragent la collaboration et renforcent le sentiment de propriété et d’engagement envers le produit.


Testing | 18 septembre 2024

Envie d'une autre lecture ?

Appel à Orateurs Lille/Lyon Testing Event 2024
24 juillet 2024

LTE 2024 : appel à orateurs !

Le LTE revient cette année avec une surprise de taille : ce n’est pas une, mais deux soirées dédiées à l’amélioration et au partage des pratiques en qualité logicielle qui se dérouleront à Lille et à Lyon en novembre prochain.
Vous souhaitez partager votre expertise, une expérience vécue ou débattre d’un sujet d’actualité en lien avec la qualité logicielle ? Nous vous invitons à proposer votre candidature pour intervenir lors de ces soirées.

Lire l'article
Deux photos de nos collaborateurs à la JFTL : la première de nos participants à la JOQ et la seconde la conférence d'Olivier et Guillaume.
17 juin 2024

On était à la JFTL 2024 !

Nos collaborateurs ont une fois de plus marqué leur présence lors de la Journée Française du Test Logiciel, qui s’est tenue les 10 et 11 juin derniers. Cinq de nos collègues se sont amusés en relevant les défis des Jeux Olympiques de la Qualité, tandis que nos conférenciers, Olivier et Guillaume, ont pris plaisir à présenter leur conférence sur l’évolution du métier de testeur.

Lire l'article
Les tests de logiciel sont une pierre angulaire du processus de développement informatique, assurant la qualité, la fiabilité et la sécurité des applications.
5 juin 2024

Le Test Logiciel au service de la Qualité

Imaginez un bâtiment sans inspections de sécurité, ou une voiture qui n’aurait pas passé avec succès les différents contrôles et normes de sécurité : cela mettrait en péril les personnes qui les utilisent.

De la même manière, des logiciels non testés peuvent entraîner des dysfonctionnements, des erreurs coûteuses et parfois même des risques pour la sécurité des utilisateurs en environnement de production, où les conséquences des défauts peuvent être désastreuses.

Lire l'article