Tests exploratoires

Le concept de test exploratoire

Depuis que Cem Kaner a inventé le terme en 1984 [Kaner 2008] [Bach 2015-1], les tests exploratoires (TE), il est devenu un incontournable des tests logiciels agiles. Cette pratique est à distinguer des tests ad hoc, car les ET sont simultanément l'apprentissage, la conception et l'exécution des tests concernant ce que vous avez appris jusqu'à présent [Bach 2004].

Pendant 15 ans, ET a été progressivement affiné à partir de la collaboration de Kaner et Bach qui a débuté en 1995 [Bach 2015-1][Bach 2015-2] pour aboutir, avec le frère de James, Jonhatan Bach, à ce que James appelle "Session-based test management" (SBTM) [Bach 2000]. SBTM semble être "ET 2.0" [Bach 2015-2]. Elle intègre la planification, la structuration, l'orientation et le suivi de l'effort de test avec un bon support d'outils lors de la conduite de l'ET [Ghazi 2017].

Le fait de "tout faire en même temps" combiné à une approche de type timebox fait de l'ET une approche agile [Nonaka 1986] [Moustier 2019-1]. En outre, elle raccourcit les boucles de rétroaction entre l'ingénierie des tests et l'exécution des tests. Elle met l'accent sur l'adaptabilité et l'apprentissage alors que l'approche de test classique implique la responsabilité et la décidabilité [Bach 2004]. Puisqu'il s'agit fondamentalement d'une approche de test adaptative avec des scénarios de test et des techniques de test émergents, elle est conforme aux projets complexes comme l'est l'agilité [Snowden 2007].

Le cadre Cynefin de [Snowded 2014].

Les idées et les réflexions de James sur les tests conduisent aux faits suivants :

• "Les scénarios de test ne sont pas des tests" [Bach 2014].
• "Le test exploratoire n'est pas une technique de test. C'est une façon de penser les tests - Toute technique de test peut être utilisée de façon exploratoire" [Bach 2004].

Impact sur la maturité des tests

L'ET répond intrinsèquement à deux des principes de test [ISTQB 2018] :

• "le paradoxe des pesticides" - comme l'ET n'est pas scénarisée, le même scénario ne sera pas réalisé de la même manière [Bach 2006].
• "Les tests dépendent du contexte - ils sont alimentés par ce que vous avez appris jusqu'à présent [Bach 2004].  

Le deuxième aspect est si important que James Bach a créé une "école de test" appelée "Context-Driven Testing" (CDT) - https://context-driven-testing.com/ - avec 7 principes qui permettent d'élever le niveau de l'ET :

1. La valeur de toute pratique dépend de son contexte.
2. Il existe de bonnes pratiques dans le contexte, mais il n'y a pas de meilleures pratiques.
3. Les personnes, travaillant ensemble, sont la partie la plus importante du contexte de tout projet.
4. Les projets se déroulent dans le temps de manière souvent imprévisible.
5. Le produit est une solution. Si le problème n'est pas résolu, le produit ne fonctionne pas.
6. Un bon test de logiciel est un processus intellectuel stimulant.
7. Ce n'est que grâce au jugement et aux compétences, exercés en coopération tout au long du projet, que nous sommes en mesure de faire les bonnes choses au bon moment pour tester efficacement nos produits.

Le CDT a conduit James Bach à établir un "modèle de stratégie de test heuristique" [Bach 2020] :

‍

La "stratégie de test", également connue sous le nom de "Quality Story" ou "Charte", est requise par le SBTM. La charte est plutôt nécessaire pour :

• garder la trace de ce qui a été testé à un niveau très élevé
• définir la mission de test pour la session de test et un plan de haut niveau qui détermine ce qui doit être testé, comment il doit être testé et les limitations associées [Ghazi 2017].
• laisser le Product Owner (PO) gérer son ROI et se mettre d'accord sur l'effort de test proposé

Cette charte fait une grande différence avec les tests ad hoc. Elle peut couvrir [Bach 2004]

• heuristique de couverture précoce [Moustier 2021-2] [Meerts 2012].
• Lecture active de documents de référence
• Attaques
• Listes des modes de défaillance
• Listes de risques du projet
• Développement de scénarios
• Modèles

Une enquête a également permis de recueillir le contenu de certaines chartes de test [Ghazi 2017] :

• C01 : Configuration du test : Description de l'environnement de test.
• C02 : Objectif du test : Partie du système à tester.
• C03 : Niveau de test : Test d'unité, de fonction, de système, etc.
• C04 : Techniques d'essai : Techniques d'essai utilisées pour réaliser les essais.
• C05 : Risques : Analyse du risque produit.
• C06 : Bugs Trouvé : Bugs trouvé précédemment.
• C07 : Purpose : Motivation pour laquelle le test est effectué.
• C08 : Définition du système : Type de système (par exemple, simple/complexe).
• C09 : Exigences du client : Spécification des exigences du client.
• C10 : Critères de sortie : Définit le critère "terminé" pour le test.
• C11 : Limitations : Elle indique ce que le produit ne doit jamais faire, par exemple, les données envoyées en texte brut sont strictement interdites.
• C12 : Journaux de test : Journaux de test pour enregistrer les résultats de la session.
• C13 : Flux de données et flux fonctionnels : Flux de données et de travail entre les composants.
• C14 : Domaines d'intérêt spécifiques : Où se concentrer davantage pendant le test.
• C15 : Questions* : Questions ou préoccupations spécifiques à la charte à examiner.
• C16 : Questions de compatibilité : Problèmes de compatibilité et d'interopérabilité du matériel et des logiciels.
• C17 : Questions ouvertes actuelles : Questions existantes qui font référence aux inconnues connues.
• C18 : Sources d'information : Documents et directives qui contiennent des informations sur les caractéristiques, les fonctions et les systèmes testés.
• C19 : Priorités : Détermine ce à quoi le testeur consacre le plus et le moins de temps.
• C20 : Caractéristiques de la qualité : Objectifs de qualité pour le projet.
• C21 : Emplacement des résultats des tests : Emplacement des résultats des tests pour que les développeurs puissent les vérifier.
• C22 : Déclaration de mission : Une ligne décrivant la mission de la charte d'essai.
• C23 : Outils existants : Outils de test logiciel existants qui aideraient les tests.
• C24 : Objectif : Ce qui doit être atteint par chaque test.
• C25 : Rapports : Notes de session de test.
• C26 : Modèles et visualisations : Personnes, cartes mentales, images liées à la fonction à tester.
• C27 : Défaillance générale : Les modèles de défaillance liés aux tests du passé.
• C28 : Couverture : Limite de la charte par rapport à ce qu'elle est censée couvrir.
• C29 : Normes d'ingénierie : Règlements, règles et normes utilisés, le cas échéant.
• C30 : Oracles : Comportement attendu du système (basé sur les exigences ou sur une personne).
• C31 : Logistique : Comment et quand les ressources sont utilisées pour exécuter la stratégie de test, par exemple, comment les personnes dans les projets sont coordonnées et assignées aux tâches de test.
• C32 : Parties prenantes : Les parties prenantes du projet et la manière dont leurs intérêts conflictuels seront traités.
• C33 : Choses omises : Spécifie ce qui ne sera pas testé.
• C34 : Difficultés : Les plus grands défis pour le projet de test.
• C35 : Architecture des systèmes : Structure, interfaces et plates-formes concernant le système, et son impact sur l'intégration du système.

(*) Vous pouvez remarquer que l'utilisation de problèmes déjà découverts exploite en fait le principe ISTQB "Defects cluster together" [ISTQB 2018].

Une autre façon de construire une charte est d'impliquer le concept de " Persona " [Hendrickson 2013][Moustier 2019-1] qui consiste à fournir un faux profil avec suffisamment d'informations pour imiter l'état d'esprit d'un stéréotype d'utilisateur. Idéalement, ce stéréotype devrait provenir du marketing, mais des personae supplémentaires peuvent être générés à des fins de tests spécifiques (disons "Kevin, un geek de 28 ans qui aime essayer des logiciels prêts à l'emploi skiddies pour casser la sécurité des systèmes").

Comme nous l'avons dit, la TE est fortement basée sur les outils. James Bach en fournit quelques-uns [Bach 2004] :

• Rapports de session de balayage : http://www.satisfice.com/sbtm/ 

• Note application de test : http://testing.gershon.info/reporter/ 

• Outil de gestion et d'enregistrement : http://sessiontester.openqa.org/ 

• Calculer les métriques : SBTExecute http://www.addq.se/styr-upp-dina-utforskande-tester-med-sessionsbaserad-testningsbtm/ 

En ce qui concerne la manipulation de l'ET en groupe, il existe un prototype d'outil [Leveau 2020] capable de : 

• partager des actions d'exploration sur un site web
• montrer les widgets déjà impliqués dans les explorations précédentes et ceux qui n'ont jamais été utilisés

Depuis SBTM, ET a été amélioré avec le "Thread-Based Test Management (TBTM)" [Bach 2010]. TBTM est une approche basée sur l'activité et est comparable aux fils de conversation qui soulèvent, sont interrompus, changent, etc. Alors que les SBTM sont limités dans le temps et engagés à accomplir une tâche (la charte), le TBTM est une généralisation des SBTM qui fonctionne même dans des environnements chaotiques et difficiles avec des interruptions et des opportunités [Gatien 2012]. Pour gérer le TBTM, un simple outil de mind-mapping peut être utilisé avec des icônes, une taille de police, une couleur, des notes ou toute autre caractéristique visuelle pour représenter les éléments suivants :  

• nouveaux fils
• les tests font une pause pour éventuellement reprendre plus tard
• jalons
• nouvelle connaissance
• tests annulés
• l'importance de certains fils
• les personnes assignées à un fil

‍

En ce qui concerne l'efficacité de la TE, des enquêtes ont été menées et plusieurs avantages ont été soulevés [Itkonen 2005] :

• L'écriture d'une suite de tests complète est longue et difficile, tandis que ET rejette cet effort.
• L'ET est un moyen de tester le produit du point de vue de l'utilisateur final.
• L'ET permet de tester une plus grande combinaison de fonctionnalités car les cas de test traditionnels sont basés sur les exigences (généralement un seul pour faciliter la traçabilité).
• L'ET aide à trouver les problèmes d'utilisabilité du logiciel.
• L'ET permet de visualiser la fonction dans son ensemble tandis que le fait de suivre un script concentre le testeur sur le scénario.
• ET est très utile pour donner un retour d'information rapide aux développeurs sur les nouvelles fonctionnalités développées.
• ET est un choix naturel lorsque les caractéristiques sont polyvalentes
• L'ET peut être considérée comme un moyen d'apprendre à connaître le produit.
• ET approfondit la question de la fonctionnalité testée
• Si l'on teste à nouveau un bug fixe avec ET, cela ne se fait pas de la même manière et permet de trouver d'autres bugs
• L'ET permet de trouver des défauts plus importants en peu de temps qu'avec des cas de test traditionnels.

Le TE est en fait si efficace que la FDA a approuvé son utilisation pour les dispositifs médicaux [Bach 2011] [FDA 2013]. Pour conclure sur l'efficacité de la TE, James Bach a déclassé en 2015 le terme de " test exploratoire ", puisque le " test " est en fait la TE et que même les tests scénarisés classiques comportent une phase exploratoire, au moins pour découvrir comment les choses peuvent être préparées et exécutées par la suite [Bach 2015-2].

Le point de vue d'Agilitest sur les tests exploratoires

Agilitest est un outil d'automatisation des scripts de test qui est jusqu'à présent la bonne stratégie de test dans les SDLC itératifs tels que les cadres agiles. C'est encore plus vrai lorsqu'il s'agit de DevOps.

Cependant, même s'ils sont automatisés, les cas de test ne sont pas des tests [Bach 2014]. L'ET devrait en fait faire partie d'une stratégie de test d'automatisation. Alors que les scripts automatisés assurent principalement les tests de régression, l'ET s'attaque aux bugs de la dernière version à livrer. Cette approche peut être vue dans la pyramide d'automatisation des tests bien connue, dotée d'un "nuage" manuel au sommet dédié à l'ET et son anti-modèle nommé le "cône de glace" [Akram 2020].

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍