Réussir son intégration d’une approche Behavior-Driven Development (BDD)

Contexte et enjeux :

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 suivantes afin que vous ayez 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 :

Processus BDD

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 :

TDD Inconvénients
  • 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.

Méthodologie BDD

Pour résumer, le Behavior-Driven Development, est une méthode de développement basée sur :

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 :

Les avantages du BDD
  • Une meilleure communication entre les intervenants
  • Un développement guidé par le comportement utilisateur
  • Un développement auto-documenté

A. 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 PO, les QA 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.
BDD Risque d'interprétation
  • 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.
BDD langage Gherkin
  • 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.

B. 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 features inutiles.
Customer Behavior
  • 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.

C. 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.
Le BDD est auto-documenté

Quelles conditions sont nécessaires pour mettre en place 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 :
BDD l'accompagnement du changement
  • 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.
  • Valider l’implication plus forte de chaque intervenant en participant à toutes les étapes qui nécessitent une validation collective.
  • 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.
BDD Automatisation des tests

Ce qu’il faut retenir !

Le Behavior-Driven Development, est une méthode de développement :

PSSST 👀

Cet article vous a plu ❤️ ? N’hésitez pas à le partager pour que d’autres puissent en profiter ! Rejoignez-nous aussi sur Linkedin pour ne rien manquer et suivre notre veille sur les contenus Product & Quality !

Partager sur linkedin
Partager sur twitter
Partager sur email