18 févr. 20202 Min

L’utilisation du BDD dans la discussion autour des User Stories

Mis à jour : 14 avr. 2020

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