Dans le développement logiciel, garantir une compréhension commune des besoins métier entre les différentes équipes constitue le nerf de la guerre. Les ambiguïtés entre les équipes métier, les développeurs et les testeurs peuvent entraîner des erreurs coûteuses, des retards et une perte d’alignement sur les attentes des utilisateurs.
C’est dans ce contexte que le Behaviour Driven Development (BDD) s’impose comme une approche efficace pour faciliter la collaboration, améliorer la qualité du produit et garantir que chaque fonctionnalité développée correspond aux besoins réels des utilisateurs.
Le BDD repose sur l'utilisation d'un langage clair et accessible pour décrire le comportement du système à travers des scénarios concrets. Ces scénarios sont rédigés en Gherkin, un langage structuré qui permet aux parties prenantes de s'assurer que les exigences sont bien comprises avant même le début du développement.
Dans cet article, nous allons explorer :
✅ Qu’est-ce que le BDD et pourquoi l’utiliser
✅ Comment rédiger des scénarios en Gherkin.
✅ Le rôle clé des "Trois Amigos" dans le BDD
✅ L’approche INVEST pour rédiger une User Story efficace
✅ Les avantages du BDD
✅ Les erreurs courantes à éviter
À travers cette exploration, nous verrons comment le BDD peut transformer la manière dont les équipes conçoivent, développent et testent les logiciels, en assurant une meilleure communication et une plus grande efficacité tout au long du cycle de vie du développement logiciel.
# 1.QU’EST-CE QUE LE BDD ET POURQUOI L’UTILISER :
En 2003, Dan North développe le concept de BDD afin d’améliorer une approche de développement antérieure basé sur le test intitulé Test Driven Development ou TDD.
L’objectif étant de favoriser La collaboration pour éviter les ambiguïtés. Il s’agit de réfléchir à comment mieux collaborer avec le métier, mieux comprendre le besoin et éviter les ambigüités afin de développer correctement du premier coup.
“Behaviour is a more useful word than test”
Dan North
Le BDD est donc une approche de développement Agile guidée par le comportement attendu du Système / application qui se concentre sur la collaboration entre les différentes parties prenantes (développeurs, testeurs, et utilisateurs métier) pour définir et valider les besoins d'une application.
# 2.COMMENT REDIGER DES SCENARIOS EN GHERKIN :
Le BDD encourage ainsi une compréhension commune du comportement attendu du système/application dans un langage accessible à toutes les parties prenantes.
Ce comportement est défini sous forme d'exemples concrets, appelés scénarios, qui décrivent comment le système doit répondre à des actions spécifiques.
Est-ce que le language Gherkin (Given, When Then ) suffit pour se faire comprendre . Certains avanceront que même si c’est un language efficace, ce dernier n’est pas une obligation dans un atelier BDD.
Pour une équipe qui n’arrive pas à communiquer ensemble, le language Gherkin peut apporter un niveau d’abstraction supplémentaire. Pour éviter cela, il faut pouvoir l’adapter au contexte dans lequel l’équipe travaille et de s’assurer qu’il apporte de la valeur.
Ainsi, sur un atelier BDD ou il s’agit de chercher la collaboration, il est conseillé que toute les parties prenantes (Métier, Développeur, Testeur, Etc.) puissent parler au même niveau de langage. Il faut par exemple éviter de parler dans un langage technique au risque de perdre les représentants métier.
Exemple :
Scénario : Connexion réussie
Étant donné que l'utilisateur est sur la page de connexion
Quand il entre des identifiants valides
Alors il est redirigé vers son tableau de bord
# 3.LE ROLE CLE DES « TROIS AMIGOS » DANS LE BDD
Dans le contexte du Behaviour Driven Development, l’approche des trois amigos représente une réunion clef où trois perspectives différentes se réunissent pour discuter et affiner les exigences avant le développement d'une fonctionnalité.
Le Product Owner (PO) :
Il définit les besoins et attentes des utilisateurs , garantit que la fonctionnalité apporte de la valeur au produit et aide à formuler les critères d’acceptation qui guideront les tests et le développement.
Le Développeur :
Il s’assure que la solution est techniquement faisable, identifie les contraintes techniques et propose des solutions adaptées et anticipe la meilleure manière d’implémenter la fonctionnalité.
Le testeur :
Il pose des questions critiques pour identifier les cas limites et les exceptions, s’assure que les scénarios de test sont clairs et automatisables et garantit que les critères d’acceptation sont testables et bien définis.
Par la suite, ces derniers formulent ensemble un scénario BDD :
Exemple de Scénario : Paiement réussi avec une carte valide
Étant donné que l’utilisateur ajoute un article à son panier et saisit une carte valide
Quand il confirme le paiement
Alors la commande doit être validée et un email de confirmation doit être envoyé
30 minutes est la durée maximale d’une session de BDD efficace Si cette dernière dure plus, c’est que la User Story n’est pas suffisamment claire.
La collaboration est le mot d’ordre au sein d’un atelier BDD.
Une User Story par meeting devra être programmée pour une session pertinente.
# 4.L’APPROCHE INVEST POUR REDIGER UNE USER STORY EFFICACE
Lorsqu’on rédige une User Story, il est crucial de s'assurer qu'elle est bien définie, compréhensible et exploitable par toute l’équipe (PO, DEV, QA).
Pour cela, on applique souvent le principe INVEST, un acronyme qui définit 6 critères essentiels pour une User Story efficace.
# 4.LES AVANTAGES DU BDD
Une compréhension partagée :
Le BDD aide l’équipe à développer une compréhension commune des attentes et des critères d’acceptation pour créer plus de valeur tout en évitant les ambigüités.
Une réduction des risques :
Le BDD permet de détecter et de résoudre les problèmes plutôt dans le processus de développement.
Une confiance renforcée :
Le BDD favorise la confiance entre les différents membres de l’équipe grâce à une communication améliorée.
Une qualité accrue :
Le BDD garanti une meilleure qualité en s’assurant que le produit d’activité répond aux attentes des utilisateurs.
# 5.LES CONTRAINTES DE LA METHODOLOGIE BEHAVIOUR DRIVEN DEVELOPEMENT
Nécessité d’un changement de culture et une collaboration
Si l’équipe n’a pas l’habitude de collaborer, la transition peut être difficile. Le BDD exige un effort de communication constant pour rédiger et valider des scénarios pertinents.
Pour y remédier, il faut organiser des ateliers réguliers avec la méthode des Trois Amigos, former les équipes aux principes du BDD, à la rédaction en Gherkin et favoriser une culture d’échange au sein de l’équipe.
Complexité et abstraction à maitriser
Il est nécessaire d’avoir une bonne compréhension du métier et des cas d’usage.
Il faut donc pouvoir échanger dans un language commun et accessible à tous afin de ne pas rester dans un niveau d’abstraction propice à l’ambiguïté. Pour cette raison, il est déconseillé de rentrer dans le language Gherkin de prime abord.
En effet, rédiger des scénarios clairs et pertinents en language Gherkin est un exercice périlleux au début nécessitant un subtil travail d’équilibriste pour contre balancer entre trop de détails et rester dans le vague.
Ainsi, il judicieux de bien définir les US en se basant sur l’approche INVEST, éviter les détails d’implémentation dans la rédaction des scénarios et enfin réaliser des revues des scénarios impliquant toutes les parties prenantes avant d’automatiser.
« It’s not stakeholder knowledge but developers’ ignorance that gets deployed into production”
Alberto Brandolini
Investissement important au début / difficulté de mise en place
Les ateliers BDD requièrent un investissement important et les résultats peuvent nécessiter du temps d’apprentissage pour l’ensemble de l’équipe avant que cette approche ne commence à porter ses fruits.
Pour contourner cette contrainte, il peut être avisé de commencer avec quelques User Stories critiques, puis de généraliser progressivement.
En outre, il est possible d’observer des gains rapides en détectant plus tôt des erreurs et en améliorant la communication.
Enfin, optez pour l’automatiser des scénarios clés uniquement pour éviter un surplus de tests inutiles.
Automatisation des tests et complexité technique :
Une fois les scénarios rédigés, il faut les lier à des tests automatisés, ce qui demande des compétences techniques. Si l’application manque d’API stables, tester uniquement l’UI peut rendre les tests fragiles et lents. Par ailleurs, un mauvais choix d’outils peut compliquer l’intégration dans le pipeline CI/CD.
Dans cette optique, il est conseillé de ne pas limiter le BDD aux tests d’Interface Utilisateur UI mais de prioriser les tests API et métier.
Il est possible d’utiliser des frameworks adaptés tel que: Cucumber (Java), SpecFlow (.NET), Behave (Python), Cypress (JS) et finalement d’intégrer les tests BDD dans le pipeline CI/CD pour une exécution régulière.
Ne pas négliger les mises à jours des scénarios en cas d’évolution du produit d’activité car des scénarios mal gérés entrainent un risque de test redondant ou inutiles qui ralentissent l’exécution du projet.
Il peut s’avérer pertinent d’effectuer une revue régulière des scénarios, d’impliquer toute l’équipe dans leur mise à jour et d’organiser ces derniers en niveaux (tests unitaires, API, UI).
« Pour réussir le BDD, commencez petit, optimisez votre approche progressivement et adaptez-vous aux réalités de votre projet ! »
# 6.LES ERREURS A EVITER
Confondre outil et méthodologie
Il est pertinent de comprendre que le Behaviour Driven Developement (BDD) est avant tout une méthodologie. Ce dernier est basé sur un état d’esprit collaboratif centré sur le comportement et la valeur métier.
L’intérêt de cette méthodologie va au-delà des simples outils (cucumber, Gherkhin, etc.) Ces derniers ne garantiront pas forcément une pratique BDD efficace.
Manquer de précision
Des scénarios trop généraux ou ambigus peuvent mener à des malentendus et des implémentations incorrectes.
Pour éviter de tomber dans le piège du manque de précision, il est préférable d’utiliser des exemples concrets et détaillés pour illustrer les comportements attendus favorisant une compréhension optimale par toutes parties prenantes.
Travailler en silo
Une bonne application de la méthodologie BDD implique le décloisonnement des équipes. Il est important de réunir toutes les parties prenantes autour de la table en les incluant dans le process, de favoriser une communication fluide entre les développeurs, les testeurs et les équipes métier, de veiller à diffuser une même vision du produit et finalement, de maintenir l’engagement de tous tout au long du projet.
Négliger la phase de découverte
Comme formulé précédemment, la phase de découverte est une des trois étapes de la méthodologie Behaviour Driven Developement (BDD). Pour bien entamer cette phase, il sera judicieux de prendre le temps nécessaire à l’exploration en profondeur des besoins et des attentes.
Par ailleurs, il s’agit de clarifier les ambiguïtés et de lever les zones d’ombres en amont du processus.
Enfin, il est crucial d’assurer une bonne compréhension des objectifs, des contraintes et dès le départ, de bien mettre en évidence les attentes des parties prenantes respectives.
Négliger la documentation
Bien que le but ne soit pas de produire de la documentation, cela ne signifie pas pour autant que la méthodologie BDD doive remplacer toute forme de documentation.
De ce fait, les scénarios de comportement peuvent être compléter par des guides utilisateurs. Il est également pertinent de tenir une documentation technique détaillée et de documenter l’architecture et la conception technique importante.
Des méthodes tels que le Business Process Model and Notation (BPMN) également connu sous l’appellation française Norme de Modélisation des Processus Métier peuvent être envisagées. Parmi les outils BPMN les mieux notés sur le marché nous pouvons trouver : Agilium, Appian BPM, Bitrix24, Hefo et Miro.
Ecrire les scénarios après le code
Partant du postulat que Le Behaviour Driven Development est guidé par le comportement attendu du produit d’activité, il est considéré hors sujet de rédiger le code avant les scénarios.
La bonne pratiqué consiste à rédiger les scénarios en amont afin de valider la compréhension des besoins avant de commencer à développer.
Trop de règles et critères
Afin de réussir un atelier BDD, il est conseillé de se focaliser sur les règles de gestions les plus importantes. Ainsi, essayer de rédiger des scénarios simples et orientés vers les comportements essentiels. Il est pertinent de garder à l’esprit que des scénarios trop complexes et comportant une multitude de détails techniques rajoute des niveaux de complexité, compromettent la maintenabilité et rendent la compréhension difficile.
Limiter le Behaviour Driven Developement aux interfaces utilisateurs
Dans le cadre du Behaviour Driven Development (BDD) une des erreurs courantes à éviter consiste à limiter le BDD aux interfaces utilisateur au lieu d'exploiter pleinement la puissance de cette approche.
Le BDD vise à aligner les parties prenantes (métier, développeurs, testeurs, etc.) sur la compréhension des besoins fonctionnels à tous les niveaux de l’application.
Il faut donc faire attention à ne pas le limiter à la couverture de l’interface utilisateur mais qu’il englobe aussi :
Une approche multi-niveaux permet de réduire la fragilité des tests, accélérer leur exécution, et mieux aligner les équipes sur les besoins métier.
# 7.Conclusion
Le Behaviour Driven Development (BDD) est une approche collaborative qui vise à aligner les équipes métier, développement et test autour d’une compréhension commune des exigences.
En s’appuyant sur le langage Gherkin, l’approche INVEST et la méthode des Trois Amigos, le BDD permet d’améliorer la qualité logicielle et de réduire les ambiguïtés.
Cependant, sa mise en place nécessite un changement culturel, une bonne maîtrise des scénarios et une intégration efficace des tests automatisés.
Pour en tirer le meilleur parti, il est essentiel d’adopter une approche progressive, adaptée au projet et centrée sur la valeur métier.