Différenciation entre BDD et ATDD : Pistes à Suivre

Par Julien Dort, Expert & Coach DevOps | Expert CI/CD | Cloud | Formation | Conférence @Gologic

L’être humain est un grand passionné d’acronymes. Il semble que notre passion de l’optimisation nous amène à vouloir augmenter le nombre de mots par minute que l’on est capable de dire, rendant parfois certains discours incompréhensibles pour ceux qui ne sont pas experts dans le domaine.

Le monde de l’informatique n’échappe pas à cette règle, au contraire. Parmi nos nombreux mariages de lettres, deux apparaissent souvent ensemble, le BDD et l’ATDD.

Le BDD est l’acronyme pour Behavior Driven Development, que l’on pourrait maladroitement traduire par “développement dirigé par le comportement attendu”. L’ATDD quant à lui signifie Acceptance Test Driven Developpement qui pourrait être formulé dans la langue de Molière comme “le développement dirigé par les tests d’acceptation”.

Si vous commencez à entendre parler de ces deux acronymes, il y a de fortes chances que vous soyez en pleine transformation DevOps. En effet, ces deux méthodologies commencent souvent à apparaître lorsque l’on souhaite pousser plus loin notre évolution sur la culture DevOps, car celles-ci permettent d’améliorer notre flux de développement et donc notre efficacité à développer des fonctionnalités rapidement et qui correspondent aux besoins du client.

Lorsque j’ai découvert ces deux acronymes, j’ai mis pas mal de temps à bien cerner les différences entre ces deux méthodologies. C’est dans le but d’aider ceux qui pourraient se retrouver dans une telle situation que j’ai décidé d’écrire cet article.

Avant de vous expliquer ce que sont ces méthodologies et leurs différences, je vais me permettre de vous raconter une histoire qui m’est arrivée pour mieux vous l’illustrer.

Il y a bien longtemps dans une province

lointaine, très lointaine

J’ai mon permis de conduire, mais je ne dispose pas de voiture. Ayant la chance de vivre dans une grande ville, l’usage que j’aurais de la voiture ne me semble pas assez important pour justifier tous les frais qui sont associés à nos amies métalliques à quatre roues.

Début d’été 2020, je ressens tout de même les limitations de mes jambes et je me mets en quête d’un moyen de transport afin d’étendre mon rayon d’action pour les activités. Cherchant à allier l’utile à l’agréable, je décide de me tourner vers les nouveaux moyens de transport électriques et mon attention se fixe sur une trottinette électrique. Je commence donc à me renseigner et décide d’aller dans un magasin spécialisé afin d’avoir des conseils professionnels au sujet de ces engins et de trouver le modèle qui me convient le mieux.

Arrivé au magasin, je suis conseillé par un vendeur sur les trottinettes électriques et deux modèles sortent du lot. Le vendeur me demande alors plus de précision sur ce que je souhaite réellement faire avec mon véhicule. Mes demandes sont d’avoir une autonomie me permettant d’aller au travail et de faire des balades d’une durée intéressante. Quelque chose d’assez compact pour le stocker dans mon appartement ou pour aller faire mon épicerie ou encore pour pouvoir emprunter les transports en commun.

Devant mes besoins, le vendeur me propose alors un autre type de véhicule. Plutôt que de prendre une trottinette, il me propose d’essayer la gyroroue, une sorte de monocycle électrique. Il me propose même quelques cours pour pouvoir apprivoiser la bête, car celle-ci nécessite quelques heures de pratique pour l’apprivoiser. Après avoir fait plusieurs cours, il fallait me rendre à l’évidence, la gyroroue répondait parfaitement au cahier des charges que j’avais (sauf sur le prix 😀 ).

Et me voilà donc l’heureux propriétaire de ce véhicule avec lequel je prends beaucoup de plaisir à avaler des kilomètres d’asphalte (et de nid de poule, on est tout de même à Montréal).

Vous vous demandez donc pourquoi je vous raconte ma vie. Et bien, ce que le vendeur vient de faire avec moi, c’est d’une certaine manière du BDD 😮

Le BDD, qu’est ce que ça mange en hiver

cette affaire-là ?

Le BDD est un principe qui a pour but de s’assurer que la fonctionnalité qui va être développée répond au besoin du client. L’objectif est de faire en sorte que les personnes qui possèdent la vision affaires (Product Owner, sponsor, consommateur, etc.), les personnes qui possèdent la vision qualité (testeurs) et les personnes qui possèdent la vision développement (développeurs, architectes, etc.) soient sur la même longueur d’onde et comprennent bien l’objectif de la fonctionnalité à développer.

Ceci afin d’ajouter des détails dans la demande au besoin ou de poser les questions sur le comportement attendu (par exemple pour des cas spécifiques) afin de pouvoir développer et tester la fonctionnalité correctement. Mais ce n’est pas tout, ici les personnes responsables de la qualité et du développement ne doivent pas seulement être passives et recevoir l’information, elles ont aussi pour objectifs de mettre au défi la proposition du client pour s’assurer que ce qu’il imagine est bien la meilleure solution pour son besoin.

C’est exactement ce qui s’est passé pour moi et mon moyen de transport du futur. Je suis venu en tant que client (vision d’affaires) avec pour besoin de me déplacer et respecter mon cahier des charges, selon ma vision, la trottinette était ce que je voulais. Or, pendant une réunion de BDD, le vendeur (ici, on pourrait imaginer que ce sont les développeurs) dispose de connaissance que je n’ai pas sur un véhicule qui répondra mieux à mon cahier des charges. Ma fonctionnalité “se déplacer” sera donc bien “développée”, mais se fera par un véhicule qui n’était pas dans ma demande initiale.

Si l’on revenait dans un contexte plus informatique ? On pourrait imaginer le cas de figure ou une personne d’affaires voudrait un bouton pour imprimer un reçu après un achat. Lors d’une réunion, le développeur comprend le contexte d’utilisation de ce bouton et propose d’imprimer automatiquement le reçu après l’achat plutôt que d’avoir à cliquer sur le bouton.

La demande initiale de la personne d’affaires : « imprimer le reçu » est comblée, mais d’une manière plus optimisée, grâce à la proposition du développeur.

Je suis certain que vous avez plusieurs souvenirs de situations où en tant que développeur (ou personne non dans le domaine d’affaires), vous avez eu une idée pour améliorer une demande d’un client.

Le résultat attendu d’une réunion de BDD est une vision claire et précise du besoin du client, du fonctionnement de l’amélioration demandée même dans les cas particuliers, ainsi que de l’assurance que, au niveau de connaissances des personnes présentes à la réunion, il s’agit de la meilleure manière de faire cette évolution. Et tout ceci avant de commencer à développer la fonctionnalité.

L’ATDD comme le véhicule dans Star Wars?

Non ça c’est l’AT-AT

De l’autre côté, l’ATDD a un autre objectif. Il s’agit dans le cas de l’ATDD de demander avant de commencer à développer la fonctionnalité, à la personne qui va accepter la livraison, quels sont les tests qu’elle va faire pour valider la fonctionnalité. En d’autres termes qu’elles sont les tests d’acceptation qui seront réalisés par le demandeur de la fonctionnalité pour accepter la livraison.

Une fois ces tests connus, les développeurs pourront les coder, afin de les automatiser pour qu’ils soient effectués régulièrement. Cette automatisation des tests permettra au développeur de savoir si sa fonctionnalité réagit comme attendu et surtout permettra d’accepter la fonctionnalité rapidement et automatiquement dès la fin du développement. On aura donc un développeur qui pourra réagir très tôt en cas de soucis, une fonctionnalité approuvée rapidement et une mise en production qui pourra s’effectuer le plus tôt possible.

Alors pourquoi le BDD et l’ATDD sont-ils souvent confondus ? Et bien, c’est parce qu’il est très courant de faire les deux en même temps dans les réunions. En effet, au gré des discussions pour s’assurer que l’on développe bien le bon requis, il sera régulièrement sujet des tests d’acceptation. Une réunion avec pour objectif de faire du BDD aura donc souvent pour livrable assez d’information pour coder les tests d’acceptation.

Il ne tiendra donc plus qu’à l’équipe de développement de les coder pour les automatiser avant de se lancer sur le code de la fonctionnalité, et félicitations, vous venez de faire du BDD et de l’ATDD, deux étapes essentielles dans votre cheminement vers votre Saint Graal : le déploiement continu !

À bientôt,

Par Julien Dort, Expert & Coach DevOps | Expert CI/CD | Cloud | Formation | Conférence @Gologic

« Détenteur d’un baccalauréat en informatique spécialisée et d’une maîtrise en recherche métaheuristique multi-objectifs parallèles, Julien Dort a suivi un parcours académique et professionnel lui permettant d’allier autant le côté Dev que Ops.
Son passage au sein de diverses organisations telles que le CRIM et la Société Générale lui ont permis d’agir à titre d’expert CI/CD et d’ambassadeur des meilleures pratiques DevOps à mettre en place.
En poste chez Gologic, il réalise actuellement un mandat comme coach en transformation DevOps au sein d’une importante institution financière. Grâce à ses excellentes habiletés interpersonnelles et son sens politique aiguisé, il contribue activement à la réussite des projets auxquels il participe. »

Envie d’en apprendre davantage sur le déploiement continu ? Lisez notre série d’articles sur les divers outils disponibles et testez-les !

Suivez-nous et partagez

Blogue

BDD ? ATDD ? Quelques pistes pour différencier ces deux méthodologies