Behavior-Driven Development : de quoi parle t-on ?
Définition et objectif du Behavior-Driven Development (BDD)
Le Behavior-Driven Development (BDD) est une approche proposée par Dan North en 2006 pour faire face aux difficultés que peuvent rencontrer les développeurs au moment de tester les applications et les logiciels conçus.
Le BDD met l'accent sur la compréhension des besoins et des attentes des utilisateurs finaux grâce à l’utilisation d’exemples concrets de comportements attendus appelés "scénarios de test". Ces scénarios de test permettent de créer une documentation claire et compréhensible par l’ensemble des intervenants du projet.
Le BDD fonctionne évidemment parfaitement avec les méthodes Agile mais en réalité, il peut être utilisé plus largement avec le même succès et dans n'importe quel type de développement de logiciel.
La syntaxe Gherkin au service de BDD
Pour être compris de tous et facilement utilisables, les scénarios de test doivent être rédigés dans un langage naturel. Gherkin a justement été conçu pour être facilement lisible par des personnes sans bagage technique, tout en fournissant une structure qui peut être utilisée par des outils de test automatisés pour exécuter ces scénarios. On retrouve des expressions comme “étant donné” (“given”), “quand” (“when”), “alors” (“then”), “et” (“and”).
Scenario: Deactivate user account
Given a user with an active account
When I deactivate the user's account
Then the user cannot log in to the site
And I receive a notification that the account has been deactivated
Les avantages du BDD
Avantage #1 - Mieux communiquer pour s’assurer de résoudre le bon problème.
Une approche BDD vise évidemment à améliorer la qualité du logiciel mais elle va aussi au-delà, et la philosophie de cette méthode est plus vaste. Il s’agit en réalité, d’apprendre et de parvenir à mieux communiquer au sein d’une équipe pour éviter de perdre du temps à résoudre des problèmes qui ne seraient en réalité pas les bons. Le BDD permet de lever d'éventuelles incompréhensions grâce à l’utilisation d’un langage commun et simple.
Avantage #2 - Avoir une meilleure compréhension du point de vue de l’utilisateur.
Au cours d’un projet, il arrive que l’on perde les bénéfices de l’utilisateur final pour se concentrer sur des problèmes de moindre importance. Le BDD vise à améliorer la compréhension des besoins des utilisateurs finaux en fournissant un cadre pour décrire les comportements attendus du logiciel de manière claire et concrète. En écrivant des scénarios de test dans un langage naturel et en utilisant des exemples concrets, les membres de l'équipe de développement peuvent mieux comprendre comment le logiciel sera utilisé et comment il doit répondre aux besoins des utilisateurs.
Avantage #3 - Le BDD permet de rendre la documentation des projets vivante et réactive.
En effet, en utilisant cette méthode pour guider le développement de votre produit, il devient possible de vérifier de manière proactive que celui-ci répond correctement aux besoins des utilisateurs en exécutant fréquemment les scénarios de test. Vous êtes donc en mesure de vous assurer que le logiciel continue de répondre aux besoins des utilisateurs au fil du temps, même lorsque le développement se poursuit.
Les meilleures pratiques BDD
#1 - 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 ?
#2 - É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.
#3 - 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.
#4 - 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 !
Pour en savoir plus sur le BDD, nous vous invitons à télécharger notre nouveau livre blanc couvrant les nouvelles tendances du testing.
