BDD : Behavior-Driven Development

Le BDD (Behavior-Driven Development) peut être présenté comme une extension logique du TDD (Test-Driven Development). Il consiste à étendre le TDD en écrivant non plus du code compréhensible uniquement par des développeurs, mais le comportement attendu d'un système que tout le monde peut comprendre. Et c'est là que ça se complique car il est pour beaucoup question de langage commun et donc de collaboration entre deux univers (métier et développement). En simplifiant grandement, le BDD va guider le développement d'une fonctionnalité, tandis que le TDD guidera son implémentation.

Cette formation présente l'approche BDD et ses enjeux. Vous apprendrez comment favoriser la collaboration entre développeur, testeur et product owner à travers différents ateliers. Vous verrez également le pont entre ces discussions à une spécification exécutable par le code.

• Appréhender les enjeux du Behavior-Driven Development
• Favoriser les discussions entre développeur, testeur et product owner
• Savoir quand faire du BDD (et quand ne pas en faire)
• Rendre exécutable des spécifications avec Cucumber

• Développeur
• Testeur ayant une fibre développement
• Architecte
• Technical Leader

• Compétences requises en programmation et génie logiciel.
• Une première expérience dans le développement piloté par les tests (TDD) et la programmation orientée objet est un plus.
• Avoir suivi la formation « Qualité des développements avec Test Driven Development : optimiser son développement logiciel par les tests » (TDD01).

Cette formation est dispensée par un·e ou plusieurs consultant·es d'OCTO Technology ou de son réseau de partenaires, expert·es reconnus des sujets traités.

Le processus de sélection de nos formateurs et formatrices est exigeant et repose sur une évaluation rigoureuse leurs capacités techniques, de leur expérience professionnelle et de leurs compétences pédagogiques.

L'évaluation des acquis se fait tout au long de la session au travers des ateliers et des mises en pratique.

Afin de valider les compétences acquises lors de la formation, un formulaire d'auto-positionnement est envoyé en amont et en aval de celle-ci.

En l'absence de réponse d'un ou plusieurs participants, un temps sera consacré en ouverture de session pour prendre connaissance du positionnement de chaque stagiaire sur les objectifs pédagogiques évalués.

Une évaluation à chaud est également effectuée en fin de session pour mesurer la satisfaction des stagiaires et un certificat de réalisation leur est adressé individuellement.

CONNEXION AVEC LE GROUPE

PARTAGE ET SYNTHÈSE DES CRITÈRES DE QUALITÉ D'UNE USER STORY

ENJEUX ET BÉNÉFICES DU BEHAVIOUR-DRIVEN DEVELOPMENT

• Quand faire du BDD ?
• Problématiques adressées
• Bénéfices directs
• Bénéfices indirects

ANALYSE DU COÛT DES DÉFAUTS DANS UN PROJET DE DÉVELOPPEMENT

• Eléments de justification économique de BDD

LE PROCESSUS : LA DISCUSSION

3 C's

• Card (story mapping / story splitting / métier)
• Conversation (3 amigos/exemple mapping)
• Confirmation (jira/gherkin)

Timing (Quand est-ce qu'on le fait?)

• Pendant le Grooming / Refinement
• Lorsqu'on prend une user story

MISE EN PLACE

• Confirmation : Gherkin / Cucumber - les anti-patterns
• Interface utilisateur
• Champs obligatoires
• Given when then pattern (testing manuel)

MISE EN SITUATION : “CONFIRMATION : GHERKIN / CUCUMBER”

SYNTHÈSE ET RAPPEL DES POINTS CLÉS DE LA FORMATION

• Ce que j'ai appris – Ce que ça change – Et maintenant
• Formalisation d'un plan d'action individuel à mettre en œuvre pour faciliter la mise en place de BDD dans son projet

• Ouvrage “Specification by Example” - Gojko Adzic
• Ouvrage “The Cucumber for Java Book de Seb Rose" - Matt Wynne
• https://cucumber.io/docs/bdd/