Rechercher

Maîtriser ses coûts de développement grâce à la méthode BDD « Behavior Driven Development »

Lorsqu’ une fonctionnalité est décrite de manière trop vague, le risque est que le produit livré ne corresponde pas exactement aux attentes. Il en résultera un dérapage des coûts et des délais du projet. Ainsi, « La correction d’un bug coûte 15x moins cher à corriger avant le développement qu’après » (source IBM Systems Science Institute).


La méthode BDD « Behavior Driven Development » renforce la collaboration entre le product owner et le développeur et réduit fortement ce risque.


Typiquement, lorsque l’on utilise la méthode BDD, chaque cycle de développement se décomposera en 3 phases : la « Découverte », la « Formulation » et l’« Automatisation ». Voyons ces 3 étapes plus en détail :


La « Découverte » :

La découverte consiste à réunir le Développeur, le Testeur et le Product owner lors d’une séance de brainstorming. Lors de cette séance, la fonctionnalité sera examinée sur tous les cas d’usage possibles. Il est important de choisir une pratique suffisamment structurée et aussi avec des exemples concrets pour spécifier les exigences logicielles . Cela lèvera les ambiguïtés et participera à l’émergence d’une vision commune sur le futur produit.


Prenons l’exemple d’un Product owner d’un site e-commerce qui souhaite ajouter les conditions générales de vente à son site. Pour décrire ce qu’il attend, il pourra par exemple présenter sous la forme d’un schéma l’ensemble des parcours possibles :



Le Product Owner peut également compléter la présentation par des maquettes écran : la présentation ne sera que plus vivante !


La « Formulation » :

Un langage est communément utilisé pour la formulation : le Gherkin. Gherkin est ce que l'on appelle un langage spécifique de domaine (DSL) et celui-ci est justement spécialisé pour la rédaction de critères d'acceptation. Les scénarios ainsi réalisés constituent la définition de ce qui doit être réalisée et constitue le contrat passé entre le Product owner et le Développeur. Le scénario Gherkin comporte cinq instructions principales :


Scénario - une étiquette pour le comportement que vous allez décrire.
Given - l'état initial du scénario
When - une action spécifique de l'utilisateur
Then - un résultat testable, généralement causé par l'action de When.
And - cela poursuit l'un des trois autres opérateurs.


Ensemble, ces instructions décrivent toutes les actions qu'un utilisateur doit effectuer pour réaliser une tâche et le résultat de ces actions. Le développeur sait alors exactement ce qui est attendu, ni plus ni moins.


Reprenons l’exemple de la fonctionnalité de « validation des conditions générales de vente». Cela se traduit en langage Gherkin par différents scénarios, le premier est le parcours principal (le client valide les CGVs) :

Scenario 1 : parcours principal
Given la page livraison est ouverte
When le client accepte les cgvs
And le client procède au paiement
Then la page paiement s’affiche

Le deuxième scénario décrit ce qui doit se passer si l’utilisateur ne valide pas les CGVs (cas d’erreur) :

Scenario 2 : cas d’erreur
Given la page livraison est ouverte
When le client procède au paiement
Then un message d’erreur cgv s’affiche

Le troisième scénario décrit comment l’utilisateur peut afficher les CGVs :

Scenario 3 : parcours d’affichage des cgvs
Given la page livraison est ouverte
When le client demande d’afficher les cgvs
Then la page des cgvs s’affiche

L' « Automatisation » :

Cucumber est l’outil qui permettra d’automatiser les scénarios Gherkin, de les exécuter et d’obtenir les résultats d’exécution.


Il est important que les scénarios Gherkins ne créent pas plusieurs instructions pour demander la même chose. Par exemple, si les scénarios utilisent indifféremment les termes "le client accepte les cgvs" et "le client accepte les conditions générales de vente", il y aura alors une double maintenance. C'est pourquoi il sera plus productif d’utiliser un outil spécifique pour gérer les scénarios Gherkin plutôt qu'un simple traitement de texte.


Lorsque vous exécutez vos scénarios Gherkin en la ligne de commande, vous obtiendrez une log d’exécution :

$ cucumber -s
Using the default profile...
Feature: livraison: actions sur la page de livraison
  When le client accepte les cgvs
  And le client procède au paiement
  Then la page paiement s’affiche (1 passed)
3 steps (3 passed)
0m0.148s

Lorsque tous les scénarios d’une fonctionnalité ont un statut d’exécution OK cela signifiera que le développement de la fonctionnalité est terminé.


42 vues0 commentaire