BDD : des bonnes pratiques aux dérives

Le BDD (Behaviour Driven Development) est une approche popularisée par Dan North en 2003, et issue du TDD (Test Driven Development), dont elle est complémentaire.

Pourquoi faire du BDD ? Précisément pour répondre aux problèmes courants avec les spécifications en mode Agile :

• Pas d’explications formalisées sur le contexte 
• Spécifications interprétables différemment selon les profils ou acteurs
• Pas forcément à jour

BDD est aussi une pratique Agile, visant à synchroniser les différents acteurs développant une fonctionnalité, en définissant clairement ce que cette pratique doit accomplir. L’objectif du BDD est bien de concevoir des tests d’acceptation, illustrant le comportement de la fonctionnalité, grâce à des méthodes comme les 3 amigos ou l’example mapping. La démarche du BDD est généralement effectuée en 3 étapes : la découverte, la formulation, et l’automatisation.

Les bonnes pratiques

La synchronisation des acteurs se fait à l’aide d’exemples co-conçus illustrant le comportement de la fonctionnalité : c'est la découverte de l’User Story, souvent réalisée grâce à la réunion des 3 amigos (profils client, développeur et testeur), qui permet d’avoir une compréhension commune du besoin, et d’écrire des scénarios d’acceptation pour valider les critères d’acceptation.

La formulation de ces exemples est réalisée grâce à un langage commun, Gherkin, facilement compréhensible des différents profils des 3 amigos. Ce langage Gherkin est un langage formaté pour écrire des tests structurés dans un langage dit naturel, et a priori compréhensible par tous. Les tests en Gherkin sont écrits avec les 4 éléments de base : GIVEN / WHEN / THEN … AND (ETANT DONNE un certain contexte, QUAND je fais une action, ALORS j’ai un résultat1 ET un résultat2).

A partir de cette formulation structurée (et formatée) du comportement de la fonctionnalité, il est possible d’intégrer ces exemples dans un outil logiciel, comme Cucumber par exemple, qui va interpréter ce langage Gherkin pour exécuter des tests d’acceptation automatisés, adaptés à ces exemples. C’est l’étape d’automatisation.

Les dérives

BDD est désormais utilisé dans de nombreuses entreprises, pour tester, au plus près des utilisateurs, le comportement de certaines fonctionnalités. Mais si la compréhension commune du besoin est obtenue grâce à l’application de BDD, il n’en demeure pas moins des confusions sur cette pratique Agile, qui peuvent conduire à certaines dérives. Quelles sont-elles ?

Le BDD est considéré uniquement comme de l’automatisation

• On perd alors l’apport primordial du BDD : la capacité à avoir tous la même compréhension de l’attendu 

L’écriture et la conception des scénarios est réalisée uniquement par le PO ou le testeur

• Dans ce cas les exemples existent. Malheureusement leur qualité est souvent insuffisante car elle n’a pas fait l’objet du regard de différents profils.

L’absence d’écriture de scénarios d’acceptation

• Il arrive que des réunions de synchronisation soient effectuées mais qu’au final aucun scénario ne ressort. C’est problématique dans le sens où une grande partie des informations se voit perdue car oubliée. De même cela force à avoir plus de personnes à ces réunions ce qui demande alors un plus fort investissement.

Des tests non compréhensibles par tous les profils

• Un test BDD doit être compris de toute les personnes de l’équipe (et des fois au-delà). Ecrire des tests qui ne sont pas compris de tous ne permet pas de s’assurer que tout le monde a compris la même chose. En général cela ne permet pas non plus au métier de vraiment valider ce qui sera développé.

Le BDD est réalisé en cours de sprint

• En cours de sprint ne veut pas dire en cours de développement. Mais, même dans le cas où le BDD est fait avant le développement ce déroulement impact l’équipe qui a du s’engager à délivrer une US qu’elle n’avait pas forcément bien compris.

L’utilisation du Gherkin considéré comme faire du BDD

• Le Gherkin est un langage. Le BDD peut prendre d’autres formes… tout comme il est possible de faire des tests en gherkin qui ne sont pas du BDD (ex : l’outil Karaté propose des tests en gherkin non compréhensibles par des profils fonctionnels).

Toutes ces dérives peuvent exister, et il convient de rappeler en synthèse la démarche de cette pratique agile BDD : avant le sprint, la pratique BDD consiste, par la découverte, à valider une compréhension commune du besoin par tous les acteurs, cette compréhension étant formulée à travers des exemples, des critères d’acceptation et des scénarios d’acceptation, qui seront ensuite implémentés dans un outil de conception et d’exécution des tests automatisés.

L’application des différentes étapes de cette démarche permettra de lutter contre les dérives de BDD et surtout sur les confusions actuellement rencontrées sur les différents termes autour du concept de BDD.