Le Behavior Driven Development n’est pas une activité de testing et ne peut être résumé au langage Gherkin ou à de l’automatisation de test.
Behavior Driven Development traduit par « développement piloté par le comportement », est une approche de développement logiciel qui vise à améliorer la collaboration entre les parties prenantes, à favoriser une meilleure compréhension des besoins métier et à produire un code de qualité.
Malheureusement, de nombreuses personnes considèrent l’approche BDD comme une simple activité de test automatisé et se concentrent uniquement sur l’écriture de scénarios en langage Gherkin.
C’est pourquoi nous allons vous aider à comprendre cette méthode BDD, expliquer ses origines, mettre en évidence ses bénéfices et fournir des conseils concrets pour réussir sa mise en place au sein de votre équipe de développement.
Les origines du BDD
Le Behavior Driven Development tire ses racines du Test Driven Development (TDD) et de la méthode Agile. Il a été introduit pour améliorer la communication et la collaboration entre les développeurs, les testeurs et les parties prenantes métier.
Le BDD a été popularisé par Dan North en 2003 pour améliorer le Test Driven Development (TDD). Il a constaté que les approches traditionnelles du développement logiciel ne permettaient pas toujours de répondre efficacement aux besoins des clients. Ainsi, il a créé le BDD pour favoriser une compréhension partagée des comportements attendus du système afin de lever les ambiguïtés.
Les bénéfices du BDD
Mieux comprendre les exigences du métiers
Le Behavior Driven Development offre de nombreux avantages pour les équipes de développement. Tout d’abord, il permet de mieux comprendre les exigences métier en les exprimant sous forme de scénarios facilement compréhensibles. Cela facilite la communication entre les développeurs, les testeurs et les parties prenantes métier, en évitant les malentendus et les interprétations erronées. Il permet d’éviter les ambiguïtés et de challenger les besoins exprimés. La collaboration et la communication sont au centre de cette démarche.
Cette méthode encourage une approche itérative et collaborative du développement logiciel. En écrivant des scénarios avant même de commencer à coder, les développeurs sont contraints de réfléchir aux comportements attendus et d’adopter une approche centrée sur les besoins du client.
Enfin, l’approche BDD favorise la création d’un code de qualité. En utilisant des outils d’automatisation adaptés, les scénarios écrits en langage Gherkin peuvent servir de spécifications exécutables. Les tests automatisés garantissent que le code répond aux comportements attendus, facilitant ainsi la maintenance et les évolutions du système.
La méthode favorise donc la coopération au sein de l’équipe de développement et de concevoir des produits de meilleure qualité.
L'approche BDD peut se décomposer en 3 étapes :
- La découverte ou l’exploration métier qui correspond à une discussion avec les parties prenantes du projet (3 amigos) et si besoin le ou les experts d’un domaine. Il s’agit d’une étape cruciale dans la mise en place du BDD. Elle vise à obtenir une compréhension approfondie des besoins métier et des comportements attendus pour proposer la fonctionnalité la plus adaptée et la plus efficace en valeur ajoutée. L’Example Mapping peut être utilisé lors de cette étape.
- La formulation pour décrire les critères d’acceptation. Cette étape consiste à exprimer les scénarios sous forme de spécifications exécutables, généralement en utilisant le langage Gherkin. Et là on parle d’utiliser le langage métier pour les écrire, d’écriture collective (pas uniquement par les développeurs seuls), de revue collective aussi (pas uniquement par le/la PO).
- L’automatisation qui n’est pas une obligation peut être effectué avec un framework intégrant le Gherkin et valider le comportement du système. Il est important de noter que l’automatisation doit être utilisée de manière sélective et judicieuse. Tous les scénarios ne nécessitent pas une automatisation complète. L’accent doit être mis sur les scénarios clés et les fonctionnalités critiques. Une automatisation excessive peut entraîner une maintenance complexe et une utilisation inefficace des ressources.
Comment mettre en place le BDD dans mon équipe ?
Pour réussir la mise en place du Behavior Driven Development dans votre équipe, il est important de suivre certaines étapes clés. Voici un mini-guide pratique :
- Découverte approfondie : Ne bâclez pas cette étape cruciale. Impliquez toutes les parties prenantes, notamment le Product Owner, les développeurs et les testeurs. Identifiez les besoins métier, les scénarios clés et les comportements attendus.
- Collaboration et communication : Le BDD repose sur une communication étroite entre les différentes parties prenantes. Encouragez les discussions régulières, les réunions de travail en équipe et l’échange d’idées pour s’assurer que tout le monde est sur la même longueur d’onde sans Gherkin.
- Écriture de scénarios : Évitez les formulations impératives et privilégiez une approche déclarative qui décrit les comportements attendus.
- Automatisation sélective : N’utilisez pas le BDD uniquement pour l’automatisation des tests. L’automatisation doit être utilisée de manière judicieuse pour valider les scénarios clés et faciliter les tests répétitifs. Ne vous concentrez pas uniquement sur les outils d’automatisation, mais accordez une importance égale à la compréhension des besoins métier.
- Impliquer toutes les parties prenantes : Assurez-vous que toutes les parties prenantes sont impliquées dans le processus de BDD. Les Product Owners apportent une perspective métier essentielle, les développeurs traduisent les scénarios en code fonctionnel et les testeurs veillent à ce que les comportements attendus soient respectés. Le cas échéant sollicité les experts de leur discipline.
Les erreurs à éviter
Lors de la mise en place de l’approche BDD Behavior Drien Development, il est important de se prémunir contre certaines erreurs fréquentes. Voici les erreurs à éviter :
- Bâcler ou ignorer l’étape de découverte : Une compréhension claire des besoins métier est essentielle. Ne négligez pas l’étape de découverte, car cela peut entraîner des erreurs de spécification et des comportements inattendus.
- Se concentrer uniquement sur les outils et le langage Gherkin : Le BDD ne se résume pas à l’utilisation d’outils et à l’écriture de scénarios en langage Gherkin. Il s’agit d’une approche globale qui nécessite une collaboration et une compréhension approfondie des besoins métier.
- Utiliser une formulation impérative dans les scénarios : Évitez d’écrire des scénarios sous une forme impérative c’est-à-dire qui décrit les détails de l’application et les actions dans la UI. Privilégiez une approche déclarative qui décrit les comportements attendus du système. Cela évitera de lier à un comportement à des détails d’affichages ou techniques.
- Exclure certaines parties prenantes : Impliquez toutes les parties prenantes, y compris le Product Owner, les développeurs et les testeurs. Une collaboration étroite garantit une compréhension partagée et des résultats optimaux.
- Faire du BDD seul dans son coin : Le BDD est une approche collaborative. Il est essentiel d’impliquer toutes les parties prenantes pour garantir une communication claire et une compréhension commune des objectifs.
Le Behavior Driven Development va bien au-delà de l’automatisation des tests et de l’écriture de scénarios en langage Gherkin. C’est une approche qui favorise la collaboration, la communication et la compréhension des besoins métier. En suivant les étapes clés et en évitant les erreurs courantes, vous pouvez réussir la mise en place du BDD au sein de votre équipe de développement. Adoptez la méthode BDD pour créer un code de qualité, répondre aux attentes des clients et favoriser une meilleure collaboration au sein de votre équipe.
