Il existe de nombreuses méthodes pour organiser ses équipes dans un contexte Agile. Il est donc parfois difficile de trouver la bonne approche pour fluidifier au mieux l’avancement du projet. L’approche Behavior-Driven Development (BDD) est souvent citée comme une organisation intéressante à mettre en place. Il est donc légitime de vérifier si celle-ci est vraiment efficace et pourquoi ?
Nous allons donc dans cet article répondre aux questions clés afin que tu aies toutes les clés nécessaires pour réussir l’intégration de cette approche dans vos équipes.
Qu’est-ce que l’approche BDD (Behavior-Driven Development) ?
Le Behavior Driven Development, ou BDD, est une méthode de développement Agile dans laquelle le produit est conçu autour du comportement qu'un utilisateur s'attend à expérimenter. Le principe du BDD est donc de préciser un « comportement désiré ». C'est matérialisé par des critères d’acceptation qui seront déclinés en scénario de test et qui serviront de référence au développement du code. Ainsi, on va appliquer une approche Shift Left Testing en incluant l’expertise QA en amont des développements en créant notamment les scénarios de test avant de commencer à développer le code.
Les étapes d’une expression de besoin d’un utilisateur lors d’une approche BDD sont donc les suivantes :
- Le métier décrit son besoin sous forme d'une expression de besoin
- Le Product Owner matérialise les comportements attendus
- Le QA rédige les scénarios de test qui valident les comportements attendus
- Le développeur écrit le code validant les scénarios de test
- Le développeur ajuste le code jusqu'à ce que le scénario de test passe avec succès
- Le QA vérifie que le scénario de test passe avec succès
- La livraison de la fonctionnalité peut alors être déclenchée !
Le BDD est donc une méthode de développement dérivée du Test-Driven Development, ou TDD, qui a émergé pour répondre aux difficultés rencontrées par cette dernière :
- L’interprétation de l’expression du besoin suite à l’utilisation d’un langage technique, non commun à l’ensemble des intervenants du projet (métier, PO, QA et développeur)
- L’imprécision sur le périmètre de test entre ce qui doit être ou ne pas être testé car celui-ci se base sur la vérification de codes unitaires successifs et non d’un comportement attendu d’un utilisateur
Afin de gommer ces difficultés, la notion de "comportement utilisateur attendu" a donc été intégrée au TDD. Ainsi les ajustements du code pour répondre aux critères d'exécution du test ne se faisaient plus sur des bouts de code successifs, mais sur un comportement global attendu.
Pour résumer, le Behavior-Driven Development, est une méthode de développement basée sur :
- L’approche Shift Left Testing
- La méthode du Test-Driven Development
- Le comportement utilisateur
- L’utilisation d’un langage commun (Gherking) à l’ensemble des intervenants sur le produit
- L’écriture des scénarios de test pour driver les développements
Quels sont les avantages de l’approche BDD (Behavior-Driven Development) ?
Les avantages de l’approche BDD sont multiples, mais ils peuvent être regroupés sous 3 grands thèmes :
- Une meilleure communication entre les intervenants
- Un développement guidé par le comportement utilisateur
- Un développement auto-documenté
Une meilleure communication entre les intervenants
L’utilisation d’un langage commun et compréhensible par tous permet de fluidifier les échanges à plusieurs niveaux :
- L’interprétation : ce langage explicite à l’ensemble des intervenants permet de supprimer «la barrière de la langue » entre le métier, les Product Owners, les Quality Aanlysts et les développeurs. En effet, le langage informatique est souvent peu compréhensible pour les intervenants moins « techniques » et il est par conséquent plus difficile de vérifier que le code développé correspond bien à l’expérience utilisateur souhaité par le métier avant de le tester. Les bugs liés à l’interprétation sont donc réduits.
- La prise de décision collective : l’utilisation d’un langage commun permet à tous les acteurs de prendre part aux décisions. Toutes les questions posées entre le comportement attendu (règles métiers, matérialisation du comportement sur l’écran…) et les équipes techniques peuvent être traduites sous forme d’exemples concrets (scénario de test et/ou critère d’acceptation) compréhensibles par tous. Un point soulevé peut donc être partagé et validé par tous les intervenants ce qui renforce l’implication de tous sur le projet.
- Un langage commun plus facile à traduire en code : choisir un langage explicite du type Gherkin avec des mots clés tels que «Given», «When», «Then», «And» permet de structurer l’expression du besoin et de faciliter la correspondance avec le code en utilisant le framework Cucumber par exemple. Celui-ci permet de transformer les scénarios d'une «story» écrits sous le format Gherkin en tests java automatisés.
Un développement guidé par le comportement utilisateur
La méthode du Behavior-Driven Development implique d’écrire les scénarios de test avant de débuter les développements. On va donc :
- Développer uniquement ce que l’on a besoin : les scénarios de test indiquent clairement aux développeurs le comportement attendu avec des exemples concrets d’expériences utilisateurs validés par l’ensemble des acteurs du projet, sans rentrer dans les détails d’implémentation technique qui restent l’expertise des équipes de développement. De plus, on évite ainsi des gonflements du code avec des développements de fonctionnalités inutiles.
- Clarifier le périmètre de test : comme nous l’avons évoqué ci-dessus, l’approche TDD qui consiste à ajuster le code jusqu’à la validation du test créé en amont permet de garantir la qualité technique des développements. Toutefois, cette approche étant très unitaire, rien ne garantit que tous ces codes unitaires mis bout à bout répondent réellement au besoin de l’utilisateur ou celui exprimé par le métier. Le codage effectué à partir des scénarios de test, et donc du comportement attendu, permet d’éviter les tests trop unitaires ou qui n’apportent pas de valeur ajoutée pour l’utilisateur.
Un développement auto-documenté
L’Agilité est aussi synonyme de documentation. Il est donc nécessaire de documenter le projet afin de le suivre et d’intégrer les nouveaux intervenants plus facilement.
L’approche BDD permet de faire en partie cette documentation sur le comportement de l’application avec l’utilisation de ce langage commun et compréhensible par tous. Cette auto-documentation s’exprime par :
- Des exemples concrets de comportements utilisateurs et de l’application détaillés dans les critères d’acceptation et scénarios de test.
- Une mise à jour simultanée du code et des scénarios de test puisque le code est drivé par les scénarios de test.
Quelles sont les requis pour implémenter l’approche BDD (Behavior-Driven Development) ?
Si l’approche BDD présente de nombreux avantages, il n’est pas toujours facile de l’implémenter dans tous les projets. En effet, certains freins peuvent apparaitre lorsque l’on souhaite s’organiser avec cette approche :
- L’accompagnement aux changements : mettre en place une organisation implique de modifier le rôle et l’implication de tous les acteurs du projet.
Il est donc nécessaire de :
1- Préciser dans un RACI (définition claire et précise des rôles et des responsabilités de chacun des acteurs d'un projet) qui participe et valide chaque étape du processus.
2- Valider l’implication plus forte de chaque intervenant en participant à toutes les étapes qui nécessitent une validation collective.
3- S’assurer que le langage commun utilisé sur le projet est bien maitrisé par tous. Il peut donc être nécessaire de faire des formations au lancement afin de s’assurer que la maitrise est égale et partagée par tous. - Un lancement au ralenti : ce point résulte en partie du point précédent. La mise en place d’une nouvelle organisation, associée à une implication plus forte aux différentes étapes du processus de la BDD, tout en accentuant sur la nécessité d’un découpage fin des user stories afin de les rendre moins complexes et accessibles à tous risquent de ralentir le projet sur les premières itérations. Toutefois, ce retard sera rapidement rattrapé par la suite grâce à la communication plus fluide et les bugs généralement moins présents avec ce type d’approche.
- La nécessité de maintenir les tests automatisés : l’automatisation des tests, si elle n’est pas obligatoire, reste un point essentiel à la réussite d’un projet mené avec une approche BDD. Ils permettent notamment de faciliter les campagnes de non régression. Toutefois, l’utilisation d’un langage Gherkin associé à Cucumber permet de faciliter le passage de l’un à l’autre, mais il ne faut pas non plus oublier de maintenir ces tests automatisés lorsque le code évolue.
Ce qu’il faut retenir de l'intégration d'une approche BDD :
Le Behavior-Driven Development, est une méthode de développement :
- Guidée par des scénarios de test
- Basée sur le comportement utilisateur attendu (et non fonctionnel)
- Utilisant un langage naturel compréhensible et utilisé par tous
- Réduisant les risques d’interprétation et de bugs
- Evitant les gonflements de code avec le développement de features inutiles à l'utilisateur
- Qui nécessite d'être approuvée par tous pour lever les freins au lancement
- Qui demande une optimisation de l'automatisation des tests pour faciliter les tests de non régression
