Bonnes pratiques du test en AGILE

ATDD VISUEL – BDD GHERKIN : Analyse comparative

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 :

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.

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 :

Un autre concept émergent 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.

Le format des scénarios est bien-sûr la première différence :

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.

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 correspondant.

L’équipe utilise la méthode des Personas (des archétypes d’utilisateurs du système). Trois Personas ont été défini : Pierre est un salarié de l’entreprise, Emma est un Manager et Joe est une personne du service RH.

Figure 1 – Workflow de test de la fonctionnalité « Gestion des déplacements » – Edité avec l’app YEST for Jira

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.

Figure 2 – Table de décision – Editée avec YEST

La scénarisation des tests en ATDD visuel consiste à couvrir les différents cas d’usage issus du workflow de test. Graphiquement, cela donne les trois scénarios de test suivants (surlignés en vert).

Figure 3 : les 3 scénarios de test possibles identifiés par YEST et visualisés sur le parcours graphique

A chaque scénario de test issu du workflow sont associées une vision textuelle et une vision de script d’automatisation. Cela est illustré pour le scénario #1 (le parcours nominal).

Vision textuelle du scénario #1

Figure 4 – Test au format textuel généré par YEST

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.

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.

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 :

— > 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).

Figure 5- Positionnement de l’ATDD visuel vis à vis du Backlog du Produit

Figure 6 – Positionnement du BDD Gherkin vis à vis du Backlog du Produit

L’automatisation des tests en ATDD visuel et BDD Gherkin suit une démarche similaire, à base de mots-clés et de 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 #1 de l’ATDD visuel.

Figure 7 : Script RobotFramework généré en ATDD visuel

L’environnement Cucumber pour le BDD Gherkin permet aussi de lier les phrases du scénarios (les fixtures) avec un code d’implémentation dans différents langages.

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.