Le Behavior-Driven Development, ou BDD, est issue de techniques de développement logicielle et l’utilisation de celui-ci pendant la discussion autour des User Stories permet de faire le pont entre le « Quoi ? » exprimé en langage usuel et le « Comment ? » exprimer en langage technique.
A. Définition
Le BDD est une méthode de développement logicielle dérivée du Test-Driven Development – TDD. Elle incite à la collaboration des différentes parties prenantes au projet logicielle, équipes de développement, qualification et management en instaurant que le comportement d’une fonctionnalité sera décrit par des phrases basées sur un canevas composé de mots clés du langage courant. La communication est ainsi facilitée entre les équipes et évite des incompréhensions inhérentes à des parties d’environnements différents. L’accent est mis sur les processus métiers auxquels le logiciel devra apporter des solutions.
B. Principe
Le BDD spécifie que les tests de tout composant de logiciel doivent être spécifiés en fonction du comportement souhaité du composant. Le « comportement désiré » consistant ici en les exigences fixées par l’entreprise – c’est-à-dire le comportement désiré qui a une valeur commerciale pour n’importe quelle entité ayant commandé la fonctionnalité logicielle en développement.
La structuration en scénario permet de formaliser l’expression des besoins avec un langage commun et facilement interprétable.
Les scénarios se présentent sous une forme standardisée.
Ainsi la description issue de la discussion autour d’une User Story sera sous la forme
Cœur de l’US
Titre Qui (En tant que…) Quoi (Je veux…) Pourquoi (afin de…)
Exemple : En tant qu’utilisateur d’un distributeur automatique de billets je veux sélectionner le montant que je souhaite retirer afin de pouvoir disposer de cette somme en liquide.
Critère d’acceptances
Ici on liste les comportements et résultats attendu par « Qui ».
Exemple : l’utilisateur du distributeur automatique de billets a dans la main le montant qu’il a demandé
Règles de gestions
L’ensemble de règles correspondant au bon fonctionnement du processus métier.
Exemple le montant sélectionné doit être délivré en un nombre équivalent de billets de 10 ou 20 € En cas d’impossibilité d’équivalence les billets de 20€ doivent être distribués en priorité
Impact SI
Ici on liste les services, bases de données et autres API qui sont impacté par la réalisation de cette US.
Exemple Il sera nécessaire de vérifier la situation du compte bancaire du client ainsi que le plafond de sa carte bancaire.
Behavior Driven Development
Le BDD permet de répondre à la question Comment l’équipe va construire la solution pour satisfaire l’objectif du client.
Format +Scénario 1 :[titre du scénario]+ Etant donné (Given) Lorsque (When) Alors (Then)
Exemples
Scenario 1: Distribution équilibrée
Etant donné que la carte de l’utilisateur est valide Et le compte de l’utilisateur est créditeur Lorsque le client sélectionne « 60€ » Alors le compte utilisateur est débité de 60€ Et l’automate distribue 2 billets de 20€ Et l’automate distribue 2 billets de 10€ Et la carte de l’utilisateur lui est restituée
Scenario 2: Distribution non équilibrée
Etant donné que la carte de l’utilisateur est valide Et le compte de l’utilisateur est créditeur Lorsque le client sélectionne « 50€ » Alors le compte utilisateur est débité de 50€ Et l’automate distribue 2 billets de 20€ Et l’automate distribue 1 billets de 10€ Et la carte de l’utilisateur lui est restituée
Auteur : Jean-Yves Ruault