La scénarisation des tests d’acceptation venant renforcer l’expression du besoin en Agile est devenue en quelques années une des pratiques fortes de l’agilité.
Cela a pour nom : ATDD – Acceptance Test-Driven Development, BDD – Behavior-Driven Development et aussi parfois SBE – Specification By Example.
Derrière ces appellations apparaissent des pratiques similaires dans leur philosophie mais différentes dans leur positionnement et leur mise en oeuvre. Ici nous comparons deux approches positionnées à des niveaux différents dans le cycle d’affinage de l’expression du besoin en Agile :
- ATDD visuel qui utilise une représentation graphique de workflow de tests, pour discuter et formuler les scénarios de test au niveau de la Feature ou du Processus Métier à implémenter, pour produire des tests au niveau applicatifs et inter-applicatifs.
- BDD Gherkin qui utilise le format textuel Given – When –Then pour définir les scénarios de test associés au critères d’acceptation de la User Story affinée, pour produire des tests plus atomiques et centrés sur une User Story.
Dans cet article, l’objectif est de comparer ATDD visuel et BDD Gherkin, de rappeler ce qui est semblable et de montrer leur différence de nature sur un exemple concret.
ATDD visuel et BDD Gherkin : ce qui est semblable
Ces approches partagent une même philosophie : la scénarisation des tests vise à renforcer l’expression du besoin et les critères d’acceptation au travers d’exemples de cas d’usage, devenant des tests d’acceptation.
Dans le syllabus ISTQB/CFTL de niveau avancé « Testeur Technique Agile », ceci est exprimé de la façon suivante pour le BDD Gherkin « …technique dans laquelle les développeurs, les testeurs et les représentants du métier travaillent ensemble pour analyser les exigences d’un système logiciel, les formuler à l’aide d’un langage partagé, et les vérifier automatiquement ». Et cela est aussi vrai pour l’ATDD visuel.
Cette définition exprime bien les points clés :
- La scénarisation des tests d’acceptation BDD et ATDD permet d’affiner l’expression du besoin en Agile sous la forme d’exemples testables
- Ces scénarios de test d’acceptation formalisent ce qui est attendu du logiciel en cours de définition et d’implémentation, et ils représentent des exemples d’usage du logiciel
- La scénarisation des tests est partagée et compréhensible par tous les membres de l’équipe Agile : analystes métier, Product Owner, testeurs et développeurs.
Un autre concept émergeant de l’agilité est commun à l’ATDD visuel et au BDD Gherkin : les scénarios de tests d’acceptation constituent une documentation vivante du produit.
Les Epics et les User Stories constituent une information volatile : lorsqu’une User Story est réalisée dans une itération, acceptée à l’issue des tests, cette expression du besoin n’a plus qu’une valeur historique, mais cela n’en fait aucunement un référentiel d’exigences.
Les scénarios d’acceptation ont vocation à durer dans le temps, en particulier parce qu’ils sont implémentés en tests automatisés de régression. Etant exécutés souvent, les tests sont à jour vis-à-vis de l’application et la lisibilité des scénarios permet le partage entre les membres techniques et non-techniques de l’équipe Agile.
ATDD visuel et BDD Gherkin : ce qui est différent
Le format des scénarios est bien-sûr la première différence :
- En ATDD visuel, les parcours applicatifs sont représentés graphiquement par un diagramme de flux d’activités, décrivant un workflow de test.
- En BDD Gherkin, le format textuel structuré en Given – When – Then, décrit un scénario individuel en termes de mise en contexte du test (la partie Given – Etant donné), d’action du test (la partie When – Quand ou Lorsque) et de résultat attendu (la partie Then – Alors).
La différence principale apparait dans ces deux définitions : en ATDD visuel, la scénarisation des tests par le workflow de test présente une vision globale de la fonctionnalité ou du processus métier couvert, alors qu’en BDD Gherkin, il s’agit de couvrir de façon atomique un critère d’acceptation d’une User Story.
ATDD visuel illustré sur un exemple
Prenons l’exemple d’une entreprise qui souhaite développer en interne la gestion des déplacements professionnels au sein du logiciel RH.
Ce projet est porté par le service RH, qui lors d’un atelier d’expression du besoin a exprimé la fonctionnalité attendue de la façon suivante :
Gestion des déplacements :
Le système devra permettre de créer une mission (par un salarié), de valider la mission (par son Manager) et de procéder au remboursement des frais de mission par le service RH.
Cet énoncé correspond à une « Minimal Marketable Feature », définie par l’Alliance Agile comme une fonctionnalité minimale qui fait sens pour le Métier. Cet aspect minimal permet de se focaliser sur la valeur première à délivrer, qui pourra par la suite être complétée.
Le workflow de test en ATDD visuel pour cette fonctionnalité est présenté en figure 1. Ce workflow a été discuté et formulé lors d’un atelier « 3 Amigos » auquel participaient 2 personnes du service RH (portant le besoin), le Product Owner de l’application RH, un testeur et deux développeurs de l’équipe. La formulation du workflow vise à aligner toute l’équipe sur les différents parcours applicatifs à implémenter. Du workflow de test dériveront directement les scénarios de test d’acceptation et les scripts automatisés correspondants.
L’équipe utilise la méthode des Personas (des archétypes d’utilisateurs du système). Trois Personas ont été définis : Pierre est un salarié de l’entreprise, Emma est un Manager et Joe est une personne du service RH.
A ce workflow, sont associées plusieurs tables de décision pour affiner les règles de gestion. Par exemple, le refus de la demande par le Manager va devoir être motivée par des raisons prédéfinies (Déplacement trop couteux, Déplacement trop long, Autre raison), tel qu’illustré dans la table suivante associée à la tâche « Validation de la demande » du workflow ci-dessus.
La scénarisation des tests en ATDD visuel consiste à couvrir les différents cas d’usage issus du workflow de test. Le scénario visuel, surligné en vert, est un exemple de test obtenu à partir du workflow.
A chaque scénario de test issu du workflow est associée une vision textuelle et une vision de script d’automatisation. La documentation du test ci-dessous correspond au scénario visuel précédent.
Le même exemple en BDD Gherkin
Le BDD Gherkin n’est pas adapté à scénariser les exemples au niveau global du workflow pour un parcours applicatif de bout en bout.
Si on essaie d’écrire en format Given – When – Then le scénario de test précédent, on atteint les limites de la lisibilité d’un scénario Gherkin lorsqu’il devient trop long et complexe (du fait en particulier du changement de Rôle entre Pierre, Emma et Joe). Et encore ! notre exemple de « gestion des déplacements » est simplifié : dans la réalité des projets, les workflows de test sont plus complexes et longs que celui décrit précédemment. Imaginez un scénario BDD Gherkin avec plus de 15 ou 20 pas de test ! Ce n’est pas fait pour cela car la lisibilité et la maintenance des scénarios BDD Gherkin deviennent alors très difficiles.
Les scénarios BDD Gherkin sont adaptés pour scénariser les critères d’acceptation des User Stories affinées, et pas pour des scénarios applicatifs ou inter-applicatifs.
Un exemple de bon usage du BDD Gherkin est de considérer un scénario de test au niveau d’un critère d’acceptation d’une User Story. Considérons la User Story « Validation déplacement / Refus » qui a été définie en affinant le besoin de la fonctionnalité de « Gestion des déplacements ». Un critère d’acceptation de cette User Story est l’indication du motif de refus « trop couteux » dont le scénario BDD Gherkin est donné ci-dessous.
US – Validation de la demande En tant que Manager Je peux refuser la demande de déplacement d’un salarié de mon équipe Afin de gérer mon budget | Scenario: Refus de la demande pour motif « trop couteux » Given Je suis connecté en tant que Emma When Pierre crée une demande de déplacement and Pierre est dans l’équipe de Emma and Emma refuse la demande de déplacement de Pierre pour motif « trop couteux » Then la demande de déplacement de Pierre est refusée avec le motif « Trop couteux » |
Le principe du BDD Gherkin est de définir des scénarios focalisés sur un critère d’acceptation et de produire le code automatisé atomique correspondant. Ce scénario BDD Gherkin pourrait être paramétré par une table de données donnant les différents motifs du refus. Nous ne l’explicitons pas pour ne pas alourdir le texte.
Résumons le positionnement ATDD visuel / BDD Gherkin
ATDD visuel et BDD Gherkin sont positionnés à des niveaux différents dans le cycle de l’expression du besoin en Agile, comme cela est illustré par la figure suivante :
- ATDD visuel :
- Les workflows de test se situent au niveau des fonctionnalités – Minimal Viable Features.
- Les tables de décisions se situent au niveau des User Stories et des critères d’acceptation des User Stories.
- BDD Gherkin : les scénarios Given – When – Then se situent au niveau des critères d’acceptation des User Stories.
Les figures suivantes montrent le positionnement respectif vis-à-vis du backlog du produit de l’ATDD visuel (Figure 5) et du BDD Gherkin (Figure 6).
Automatisation en ATDD visuel et BDD Gherkin
L’automatisation des tests en ATDD visuel et BDD Gherkin suit une démarche similaire, à base de mots-clés et, si utile, de table de données. Les scripts de tests sont générés automatiquement par les outils supports et les développeurs ou automaticiens de test codent et maintiennent les mots-clés d’automatisation.
La figure suivante montre un script Robot Framework généré avec YEST pour le scénario de la figure 3 de l’ATDD visuel.
L’environnement CucumberStudio pour le BDD Gherkin permet aussi de lier les phrases du scénarios avec un code d’implémentation dans différents langages (glues ou Fixture) .
En synthèse
Alors quelle approche choisir : ATDD visuel ou BDD Gherkin ? Eh bien cela dépend évidemment de votre contexte et de vos objectifs dans la mise en œuvre de pratiques de test en Agile.
Si votre contexte est celui d’applications du SI d’entreprise, avec des workflows Métier à définir, implémenter et tester, alors l’approche ATDD visuel est pertinente car permettant d’impliquer les rôles orientés Métier dans des discussions concrètes sur les exemples de parcours applicatif. Le formalisme de workflow est habituel pour les analystes métier et les analystes fonctionnels, et les tables de décision permettront de discuter et détailler les différents cas d’application des règles de gestion.
Le BDD Gherkin est une bonne approche pour raffiner dans le détail, avec les parties prenantes Métier, les critères d’acceptation au niveau de chaque User Story, discuter les exemples, formuler le scénario et automatiser le script correspondant.
Suivant vos objectifs et votre contexte applicatif, vous pourrez utiliser l’ATDD visuel pour une vision globale de la Feature et produire des tests applicatifs ou inter-applicatifs, et/ou utiliser le BDD Gherkin pour scénariser les tests au niveau de la User Story et produire des tests courts et atomique au niveau du critère d’acceptation.