Halte aux idées reçues. Bien que le terme BDD figure dans une bonne partie des offres d’emplois, des CVs et des pratiques d’équipe de développement, la méthode reste largement incomprise et mal utilisée. Souvent assimilé à une pratique de test, le BDD peut vous faire perdre beaucoup de temps, d’argent et d’énergie en l’utilisant de la sorte. Le Behaviour-Driven Development est avant tout un moyen de favoriser la collaboration au sein de l’équipe produit. Faisons le point sur cette pratique.

Un grand nombre d’équipes ou de DSI pensent bien faire en implémentant des “tests” BDD (Behaviour-Driven Development). Ce qui semble être une bonne approche au départ vire souvent au gouffre financier. Comme tout autre outil, le Behaviour-Driven Development peut améliorer le quotidien de votre équipe s’il est bien utilisé ou tourner au cauchemar dans le cas contraire. 

Si vous n’êtes pas convaincu par le fait que le BDD n’est pas une approche de test vous pouvez toujours jeter un oeil aux tweets de Daniel Terhorst-North (aussi connu sous le nom de Dan North) développeur logiciel, coach agile et Technologist à l’origine de l’approche BDD, ainsi qu’à deux articles de blog de chez cucumber bdd is not test automation et SpecFlow Why is BDD one of the most misunderstood concepts?

inté-tweet-article

voir le tweet

ainté-tweet-article-2

voir le tweet

LA PETITE HISTOIRE DU BDD

Le terme Behaviour-Driven Development a été initié en 2003 par Dan North comme un moyen d’enseigner le TDD (Test-Driven Development ou développements pilotés par les tests) aux développeurs, les poussant ainsi à penser le TDD comme une pratique de conception et non une pratique de test. Dan North trouvait le mot “comportement” (Behavior) plus approprié que “test” et utilise dès lors le terme BDD pour parler de cette approche spécifique. Dans la foulée, il crée l’outil JBehave pour se substituer à JUnit, ainsi que tout le vocabulaire et les références liées aux tests. 

À la même période, Eric Evans introduit dans son best-seller Domain-Driven Design la notion de langage omniprésent (Ubiquitous Language). Un langage basé sur le domaine métier et partagé entre les développeurs et les utilisateurs.

Dan North et Chris Matt (collègues Business Analyst de Dan) se mettent à imaginer un vocabulaire commun capable de réunir les Business Analysts, les testeurs, les développeurs et les représentants du métier. Dès lors, le BDD passe à une approche qui vise à améliorer la communication en éliminant les ambiguïtés entre les différents intervenants (techniques et non techniques) tout en se focalisant sur la valeur apportée par chaque comportement du logiciel.

LES TROIS PHASES DU BDD

Concrètement, l’approche BDD consiste à comprendre et à valider les exigences métiers au moyen d’exemples illustratifs. Elle se décline en 3 étapes Découverte, Documentation et Automatisation

inté-image-article-bdd

DÉCOUVERTE

L’étape de découverte est la plus importante de l’approche BDD. Il s’agit de discuter du comportement d’une fonctionnalité et de débusquer tous les critères d’acceptation et les cas limites. La discussion se fait entre les célèbres “trios d’amis” (Three amigos) à savoir les développeurs, le Product owner et le testeur. Rien ne vous empêche d’inviter d’autres personnes susceptibles de vous aider à comprendre un comportement du logiciel. Vous pouvez aussi vous aider d’ateliers d’exemple mapping.

inté-image-article-bdd-3

DOCUMENTATION

La deuxième étape consiste à documenter les discussions de la phase de découverte, avec un langage et des scénarios précis. Le document résultant doit être lisible et compréhensible par toute l’équipe ainsi que par les parties prenantes métiers. Dès lors que cette documentation est validée par les trois amis elle devient la source unique de vérité, la référence.

La plupart des outils d’automatisation des scénarios BDD utilisent la syntaxe Gherkin qui permet d’écrire des scénarios de test compréhensibles par des individus non techniques :