BDD vs ATDD : jolis TESTS ou SPEC EMERGENTE ?

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/iunr2x

[@TheLimande]

merci pour cette vidéo inspirante, ça me rappelle un serious game qu'on faisait autour du jeu du "Cul de Chouette" de Kaamelott, on ne donnait pas les règles mais on joue directement, on notant les exemples, on peut faire émerger facilement les règles

[@TheLimande]

pour moi, ATDD n'est à appliquer que pour des technologies où les développeurs n'ont pas la possibilité de faire du BDD, je pousserais BDD dans tous les autres cas

[@ScrumLife]

Merci Emmanuel pour l'exemple du cul de chouette :D Comment ferais-tu pour amener au BDD des développeurs qui ne connaissent pas, et donc ne seraient pas convaincus ? -- Constantin

[@TheLimande]

@@ScrumLife je leur montre ce que c'est, la documentation vivante qui en ressort. Le côté spécifications exécutables

[@TheLimande]

@@ScrumLife souvent ceux qui ne connaissent pas mais font déjà du TDD ont un gap plus facile à surmonter : au lieu d'inventer seul un test à partir d'une règle écrite par quelqu'un qui n'est pas là, tu discutés avec celui qui connaît le besoin et celui qui va tester. Le côté accès au demandeur et à celui qui va valider est top. Le plus difficile est de faire participer le dev à l'émergence des règles et exemples, ne pas laisser la main au testeur.

[@TheLimande]

Pour ceux qui codent en legacy... sans test, je peux pas grand chose pour eux, ils doivent évoluer sinon il ne feront jamais de CI/CD ou DevOps

[@benoitgalati6392]

Merci pour cette vidéo qui m'a permis de mieux comprendre ces 2 méthodes :-)

[@ScrumLife]

Avec plaisir ! Est-ce des outils ou des approches que tu pratiques ? -- JP

[@benoitgalati6392]

@@ScrumLife Non, mais je connaissais déjà un peu. D'ailleurs est-ce que ces approches impliquent forcément l'implémentation de specs exécutables ou l'on peut se contenter de la phase de discussion comme avec l'example mapping ?

[@ScrumLife]

On peut tout à fait se contenter de la discussion et déjà retirer l'essentiel de la valeur de l'approche. Attention tout de meme, un filet de non-régression automatisé reste un passage obligé. Mais certaines équipes n'ont pas un besoin fort d'avoir une documentation vivante du produit, ni de garantir que ce qui sort est bien ce qui a été discuté. Dans ces équipes, les discussions + une excellence technique sans faille sur les tests automatique peuvent tout à fait suffire. -- JP

[@TheLimande]

@@ScrumLife est ce qu'on peut vraiment prétendre pratiquer BDD et ne pas forcément implémenter des specs exécutables ? j'ai du mal avec ça, c'était la différence majeure que je donnais entre ATDD et BDD

[@damienlebris7119]

Encore une super vidéo. :) Merci

[@ScrumLife]

Merci Damien ! Que retiens-tu tout particulièrement de la vidéo ? -- JP

[@LyesDoar]

Merci pour cette explication. c'est la 1er fois ou je trouve une explication claire entre la différence de la BDD et l'ATDD. Le mot revue de spec décrit bien l'ATDD, et ca se passe exactement comme ca ds mon équipe. et cela est vraiment va contre le sens de l'agilité définit dans le célèbre livre de "story mapping", qui dit que l'objectif de scrum c'est pas avoir des spec courte au format d'user sory à la place de cahier de charge, mais d'avoir une discussion d'équipe pour partager une compréhension mutuelle de l'user story, et cette compréhension se traduit en exemples écrit en format gherkin ou en format de règles. 1- mais sur quoi tu te base pour donner la définition de BDD? est ce que c'est votre interprétation? est ce que vous pouvez nous citer cette définition chez les créateurs de la BDD comme quoi on crée des règles à partir des exemples, mais pas l'inverse? 2- au final pour vous, la forme final de la BDD et l'ATDD est la même, ce qu'il diffère est seulement la facon de le produire, c'est bien ca ?

[@ScrumLife]

Bonjour Ilyes, merci pour ton message et pour le partage de ta réflexion. Pour te répondre : Concernant le 1, la définition donnée n'est pas "académique", elle se base pour l'essentiel sur l'interprétation des noms ainsi que de l'expérience de ce qui "le vrai BDD", "le BDD mal compris", "l'ATDD", etc. Il faut dire que sur ce sujet, beaucoup d'avis divergent. Des personnes décriront le BDD comme le regroupement d'un ensemble de pratiques, dont le Specification by Example (merveilleusement illustré par l'Example Mapping), le Living Documentation, les 3 Amigos (que facilite l'Example Mapping) et l'ATDD justement qui consiste à simplement automatiser les tests d'acceptation dans une démarche Test First. Finalement, cette vidéo était l'excuse d'expliquer ce que sont des spécifications émergentes et comment les mettre en place, tout en faisant réfléchir autour de ces termes "ATDD" et "BDD" qu'on retrouve souvent et qui sont malheureusement réduit par de nombreuses personnes à "faire du Given-When-Then". Concernant le 2, je suis d'accord avec votre reformulation. Sachant qu'en produisant différemment le résultat, on n'arrive justement pas au même résultat ! 😁 Au plaisir de continuer l'échange, -- JP

[@Ragi3l]

Merci de m'avoir apporté un regard nouveau sur l'example mapping et de m'avoir permis d'entrevoir un peu plus l'ATTD et le BDD. J'ai juste un soucis : la conclusion laisse entendre que le BDD créé une solution meilleure / plus simple pour l'utilisateur. Je ne comprends pas comment la solution peut être meilleure alors qu'autour de la table on a que des membres de l'équipe (et pas d'utilisateurs ou d'ux). Quelqu'un peut éclairer ma lanterne ?

[@ScrumLife]

Je vais envisager 2 situations possibles : solution à la demande et approche produit. Dans le cas d'une solution à la demande, le client / utilisateur est clairement identifié et ce serait dommage de ne pas l'inviter dans ces ateliers. Dans le cas d'une approche produit, le fonctionnement possible est moins évident. On peut imaginer faire un travail en amont sur les User Stories, puis faire l'atelier sur la base des informations collectées. Précisons que dans tous les cas l'UX designer devrait etre un membre de l'équipe et devrait donc etre présent à l'atelier. "Developer" en Scrum indique n'importe quelle personne qui contribue à la construction de l'incrément produit. Que penses-tu de ces propositions ? Arrives-tu à te projeter ? -- JP

[@Ragi3l]

​@@ScrumLife Je suis d'accord avec ces deux idées dans les grandes lignes. De mon expérience : 100% d'accord avec la première (solution à la demande) mais pour l'approche produit ça coince. J'aurai tendance à dire qu'il y a toute la partie reseach / discovery qui doit être faite "à un moment". Probablement avant. Sur un sprint cela me semble trop tendu (impossible?) sur un scrumban / kanban je vois plus.

[@Ragi3l]

Et je ne suis pas fan de l'idée "On montre en review des résultats de test utilisateurs" (non fonctionnel en prod).

[@vipinfatawat8357]

Please make the video in a common language like english for better reach to maximum people through out the world.

[@scvroin]

Is better in french than to be in english with a french accent. You may use the translation or look for similar videos in english.

[@ScrumLife]

Also feel free to join the SRT team to help provide subtitles and translations! JP