Projets Agiles : Comment utiliser la méthode BDD ?

Dans cet article vous découvrirez la méthode et les principes du BDD dans les projets agiles.

1. C’est quoi l’approche BDD ?

Définition BDD – Behavior Driven Development

Le Behavior-Driven Development, ou 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.

2. Le Principe du BDD dans un projet agile

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 qui utilisent BDD se présentent sous cette forme standardisée :

Titre
Qui
Quoi
Pourquoi

Scénario 1 :
Etant donné (Given)
Lorsque (When)
Alors (Then)

Scénario 2 :
…

Pour un cas un peu plus concret cela donnerait par exemple dans le cas d’un distributeur de billet :

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

Consultez notre dernier webinar sur les spécifications BDD.

3. L’automatisation dans l’Agilité

Le BDD définissant un canevas pour la description des fonctionnalités il est aisé de créer des tests automatisés pour les scénarios. Le langage Gherkin, « Given – When – Then » utilisé dans l’exemple précédent, permet via des frameworks disponibles en de nombreuses langues, de traduire aisément les scénarios en test.
Ces scénarios étant établis dès le début du cycle de développement les équipes de qualifications peuvent très tôt préparer les tests pour les confirmer, et les automatiser. Dans un cycle d’intégration continu les tests sont alors prêts pour exécution quand les développeurs ont traité la fonctionnalité. Leur automatisation permettant également de les intégrer facilement dans des cycles de test de non-régression.

4. Les outils BDD/Agile

Des outils comme Cucumber (open source) ou Hiptest (éditeur Français, utilisé par ALL4TEST sur certains projets en France) permettent de mettre en œuvre cette approche BDD / Agile.

5. Les meilleures pratiques BDD

Commencer par le pourquoi

Définissez clairement et de manière transparente ce que vous attendez du BDD. Posez-vous les questions suivantes : Qu’est-ce que le BDD va m’apporter ? Et à mon équipe ? Et aux utilisateurs ? Quels sont les problèmes que je souhaite résoudre ? S’agit-il d’améliorer la communication entre les équipes ? De réduire les erreurs réalisées par les développeurs ? De faciliter le travail des testeurs ?

Écrire des scénarios de test clairs et concis

Écrivez des scénarios de test : commencez à écrire des scénarios de test en utilisant la syntaxe Gherkin. Assurez-vous que les scénarios décrivent clairement les comportements attendus par l’application. Utilisez un langage naturel et concret qui soit facilement lisible par tous les membres de l’équipe qu’ils aient des compétences techniques ou non. Vous pouvez par exemple, utiliser des exemples concrets pour décrire les comportements attendus du logiciel. Par ailleurs, veillez à ce que chaque scénario soit un cas de test indépendant et puisse être exécuté de manière autonome. Soyez le plus précis possible en évitant d’utiliser des termes vagues ou ambivalents.

Exécuter régulièrement les tests et les automatiser

Utilisez un outil de test automatisé pour exécuter vos scénarios de test et vérifier que le logiciel fonctionne comme prévu. Cela vous permettra de vérifier de manière proactive que le logiciel continue de répondre aux besoins des utilisateurs au fil du temps.

Faire participer toutes les parties prenantes

Pour que l’approche fonctionne, elle doit être comprise par l’ensemble des intervenants. Il est important de communiquer sur vos objectifs et sur l’intérêt de BDD pour donner un maximum de sens à votre démarche.

Le BDD est un processus continu. Il est donc recommandé de réviser régulièrement les scénarios de test et de mettre à jour le processus global de BDD pour s’assurer que l’on tire le meilleur parti de cette approche. Une occasion supplémentaire d’échanger et de communiquer avec l’ensemble des parties prenantes du projet !

Vous avez une question technique sur le sujet ? N’hésitez pas à nous contacter !