Merci beaucoup. Donc d'abord, c'est ma première fois, donc soyez indulgents. Mais ça devrait bien se passer pour tout le monde. J'ai tendance à parler beaucoup aussi, donc n'hésitez pas, si à un moment vous êtes fatigué, à faire « je suis bourrée ». Donc le BDD, comprendre ce que c'est vraiment, les erreurs à éviter. Peut-être un petit point d'introduction d'abord, c'est qu'on dit « driven ». Alors pourquoi je le dis ? Parce que j'entends souvent « behavior-driven development » ou « test-driven development » et non. En fait, petit rappel phonétique, c'est bien « behavior-driven development » de la même manière qu'on dit « test d'acceptation » et pas « test d'acceptance ». « Acceptance » c'est « acceptance test » en anglais. Enfin voilà, c'est des petits détails comme ça, mais je ne suis pas qualiticienne pour rien. Donc voilà. Un petit sommaire juste pour que vous ayez en tête où on se situe à peu près, parce que la présentation, comme je le disais, elle sera un peu chargée. Donc voilà, en gros au début, on va commencer sur vraiment comprendre ce que c'est le BDD, un petit peu la philosophie, les points vraiment essentiels, pour ensuite faire un passage rapide sur la mise en place et les outils qui existent pour avoir un peu le panorama en fait, parce que finalement on entend parler de plein d'outils, mais sans savoir comment les positionner et quand est-ce qu'on les utilise. Le côté plus sur le fait que le BDD c'est quelque chose qui s'acquiert, c'est-à-dire que ça a l'air simple, mais le bon BDD ce n'est pas simple. Mettre en place vraiment bien le BDD ce n'est pas simple, surtout sur la partie rédaction des scénarios Gherkin et les limites aussi du BDD, donc on verra ensemble. Donc le BDD, qu'est-ce que c'est ? D'abord, petit sondage à main levée parmi vous, qui a déjà entendu parler du BDD ? Ok, très bien. Qui pratique déjà le BDD ? Qui aimerait pratiquer le BDD ? Qui dit oui ? Ok, et du coup pourquoi ? Ceux qui aimeraient pratiquer le BDD, pourquoi vous aimeriez franchir le pas du BDD ? Donc je change un peu la dernière question, vu que personne ne fait de BDD, mais c'est la mode ? La qualité en continu ? Oui, d'accord. Nous on l'expérimente, et en fait c'est pour essayer d'avoir la seule source de vérité entre les user stories et ce qui est en code, et essayer d'avoir un meilleur suivi. Plus le côté documentation vivante alors. Très bien, et les autres ? Ok, du coup on va faire un petit nuage de mots. Quand je vous dis BDD, du coup qu'est-ce que vous, d'après ce que vous avez pu lire, voir, entendre, quels sont les mots qui vous viennent à l'esprit en fait ? L'écran est blanc, mais BDD, ça vous évoque quoi ? La solution Gherkin. Gherkin, oui, effectivement. Compréhensible, intelligible. Compréhensible, intelligible, ok. Et quand tu dis intelligible, c'est intelligible par qui du coup ? Par tous les membres de l'équipe. Oui, c'est une grosse partie du truc. Tiens, un nouveau venu. Effectivement, souvent quand on entend BDD, on entend Gherkin. C'est effectivement le premier mot qui vient, avec souvent derrière ce qui constitue Gherkin, ces fameux trois mots clés principaux, given, when, then, la structure, les scénarios. On entend aussi parfois test, TDD, DDD. Trois Amigos, je ne sais pas si ça vous parle, la réunion des trois Amigos. Cucumber, les outils directement, forcément. Behat, si vous faites plutôt du PHP. On a parlé de Living Documentation, effectivement, ce sont des termes qui reviennent. Et après, un peu plus sur les personnes, pour ceux qui connaissent un peu mieux, on a Dan North, John Ferguson, etc. Mais effectivement, ça fait plein de trucs un peu, et par nous, ce soir, l'idée, ça va vraiment être de venir mettre de la structure dans tout ça en fait. Et donc du coup, qu'est-ce qui a fondé le BDD ? Enfin, pas qui, mais qu'est-ce qui a fondé le BDD ? En fait, le BDD a deux origines. La première, c'est le TDD, donc Test Driven Development. Sans m'éterniser, en gros, la philosophie du TDD, c'est plus une pratique vraiment de développeurs qui dit qu'on va écrire un test avant d'écrire le code qui lui correspond, ce qui est un changement de paradigme par rapport à avant où on écrivait le code, puis on venait inventer les tests qui venaient tester la chose. Donc c'est le fameux Red Green Refactor. En gros, on écrit un test, on sait qu'il va fail puisque le code qu'il implémente n'existe pas, on écrit le code, on relance le test, le test normalement devient vert, et ensuite, en fait, l'idée, c'est de créer un patrimoine de tests automatisés qui permet ensuite de garantir et de sécuriser les différents développements, et notamment quand on remanie le code, quand on refactor, d'être sûr qu'on n'a rien pété ailleurs. Donc la philosophie du TDD, elle est bien. Il y a beaucoup, de plus en plus de développeurs qui mettent ça en place. Le problème, c'est qu'à l'origine, en tout cas, les gens étaient en mode, moi je veux bien écrire des tests avant, mais dans les tests, je peux en écrire plein, jusqu'où je vais, par quoi je commence. En gros, ils étaient un peu perdus. Et à cette question-là, Dan North, le papa du TDD, a répondu à cette question en disant, en fait, finalement ce qu'on va tester, c'est ce qui apporte de la valeur au produit. Donc j'ai dès maintenant envie de mettre un point d'alerte. Moi, quand j'entends valeur produit, je pense PO. Enfin, je ne sais pas vous, mais voilà, ça montre déjà un premier point qui est que le PO, ou plutôt le BDD, n'est pas quelque chose réservé aux développeurs. C'est vraiment, le PO entre dans la boucle, parce que c'est, enfin, valeur produit, c'est le PO qui est le garant de la valeur produit. Et donc du coup, Dan North, il part de ce postulat-là, et en 2003, il remplace du coup le test de TDD, donc de Test Driven Development, par Behaviour, et ça devient le BDD, Behaviour Driven Development. Et parallèlement à ça, en fait, il crée un outil qui s'appelle GBehave, qui vient littéralement, pour lui, remplacer GUnit. Donc GUnit et GBehave, c'est vraiment avec un langage Java. Mais ensuite, par la suite, on verra qu'il y a eu d'autres langages qui ont été couverts. Alors tout ça, si vous voulez vraiment en connaître plus, n'hésitez pas à aller voir son blog dannorth.net, c'est très, très complet. Moi, j'ai vraiment appris plein de choses là-dessus. Ce sera beaucoup plus poussé pour vous, mais voilà. L'idée, en tout cas, c'est de vous montrer le premier point, le premier parent du BDD. Et le deuxième parent, parce qu'en fait, Dan North, il n'était pas non plus tout seul, c'est lui qui a inventé le truc, mais il était quand même accompagné. Le deuxième parent, c'est vraiment le DDD, le Domain Driven Design, où l'idée, en fait, c'est de créer des modèles qui répondent à une problématique métier. C'est-à-dire qu'en gros, le DDD, son cœur de sujet, c'est de remettre le métier et le sens au centre. Et un des outils pour ça, c'est de faire parler toute l'équipe le même langage. C'est ce qu'on appelle le fameux ubiquitous language. Et donc, Liz Keogh et Chris Matts ont rejoint Dan North sur cette histoire de création de BDD, et se sont inspirés des concepts du DDD, la valeur métier, surtout le ubiquitous language, pour avoir cette idée d'une équipe qui parle le même langage de A à Z, en fait. Et sur cette idée-là, ils ont inventé le langage Gherkin, qui est finalement une manière de structurer les choses pour faire en sorte qu'au sein des équipes, tout le monde parle le même langage via les mots clés de l'ubiquitous language, et dans une structure, given, when, then, qui permet en fait de cadrer et de systématiser les choses. Donc le BDD, point important, qu'est-ce que ce n'est pas, finalement ? Finalement, le BDD, ce n'est pas une méthode de test. Souvent, les gens font cette erreur-là, et il faut vraiment vous le sortir de la tête. Pour le coup, moi, je suis testeuse, qualificienne. Qualificienne, c'est peut-être un peu... Mais ce n'est pas une méthode de test. En tant que testeur, moi, en tant que testeuse, je suis frustrée par le BDD, parce que ça ne va pas assez loin. Mais il n'empêche que ça reste une approche intéressante en termes de qualité produit. Le BDD, ce n'est pas non plus dédié aux développeurs. On l'a subrepticement soufflé tout à l'heure via le côté valeur-produit. Mais si vous avez une équipe où c'est les développeurs qui ont la charge du BDD, a priori, vous ne faites pas du BDD. On verra pourquoi. Et enfin, le BDD, ce n'est pas juste une question de délivrerie. Donc ça rejoint un peu le reste. Ce n'est pas juste une question de qualité produit au sens de bienfait. C'est aussi une question de discovery, avec le bon produit. Et justement, tac ! Mais alors, le BDD, c'est quoi ? En fait, si on devait le définir, c'est vraiment une méthode globale et agile qui permet de garantir la qualité du produit. Et vraiment, comprenez-le comme une méthode agile, au même titre que Scrum, par exemple. Les deux, d'ailleurs, sont compatibles. Il n'y a pas de souci sur ça. Mais c'est vraiment une méthode, c'est-à-dire une méthode d'équipe, d'organisation de l'équipe. Autour de quoi ? Autour de la valeur produit. Parce qu'en fait, ça, c'est une phrase que vous retrouverez tout le temps et qui est très, très à la mode en ce moment quand on parle de qualité. Mais pourquoi elle est à la mode et pourquoi elle va durer aussi ? C'est parce qu'elle représente complètement l'idée de ce que c'est la qualité. La qualité, c'est vraiment « build the right product » et « build the product right ». Avec ce côté, avant tout, le bon produit, c'est-à-dire celui qui va rencontrer ses utilisateurs. Et là, on est vraiment sur le travail du PO de s'assurer qu'on répond à un besoin, qu'on répond bien aux besoins, etc.
Et de l'autre côté, build the product right, c'est-à-dire bien le produire, éviter qu'il y ait des bugs, que ça ne soit pas performant, que ceci, que cela, enfin voilà, le côté plus, ce que j'ai envie d'appeler « delivery », avec vraiment l'implémentation concrète, quoi. Et donc du coup, ce qu'il faut que vous reteniez, c'est que le BDD, c'est de la collaboration avant toute chose, c'est-à-dire qu'en fait, si vous avez du BDD sans collaboration, vous ne faites pas du BDD. Je reviens juste sur la slide précédente, c'est comme les gens qui vous disent « on est agile parce qu'on a trois post-its et qu'on fait des réunions », un daily stand-up, peu importe les réunions, une rétro, une démo, l'essence de l'agilité, ce n'est pas ça. De la même manière, le BDD, si vous ne collaborez pas, vous ne faites pas du BDD. Vous pouvez écrire des scénarios Gherkin « given when then », vous pouvez faire toute votre vie, si vous ne collaborez pas, vous faites autre chose, mais pas du BDD. Parce que l'objectif numéro un du BDD, c'est d'aligner les équipes. On vous disait tout à l'heure que le DDD était un des parents, ben voilà, on retrouve vraiment cette logique-là, c'est collaborer avant tout. Et l'idée, c'est vraiment, entre guillemets, de perdre du temps en amont pour en gagner en aval, et on n'en perd pas au final, puisqu'on se rend compte que, finalement, ça aligne tout le monde, ça fait gagner du temps à tout le monde, on ne perd pas de temps en questions-réponses. Donc ça, vraiment, l'objectif premier, c'est la compréhension commune, le fameux shared understanding des Américains. Et le deuxième objectif, c'est justement le côté réflexion collective, c'est-à-dire que, pour ceux qui ont déjà entendu parler de la réunion des 3 Amigos, c'est typiquement le moment où, finalement, on vient confronter les différents points de vue. On a le PO qui vient avec un besoin, une idée, un début de solution potentiellement, en fonction de comment on est organisé, mais derrière, il peut y avoir des enjeux marketing, il peut aussi y avoir des contraintes purement techniques, il peut y avoir des... Enfin, l'idée, c'est vraiment de regrouper les gens pour faire en sorte qu'on discute et on lève un maximum d'obstacles. Donc, dans ce côté réflexion collective, il y a la co-création, mais il y a aussi le fait de dérisquer les choses, en fait, parce que plus on rend propre en amont, plus c'est fluide par la suite. Et donc, ce moment où on dérisque, c'est cette fameuse réunion des 3 Amigos ou 3 Amigos, ou plus, j'ai mis ou plus, parce qu'en fait, l'idée, c'est vraiment de réunir tous les stakeholders, tous ceux qui peuvent apporter quelque chose d'intéressant. Alors évidemment, ça peut avoir un coût de regrouper jusqu'à 6, 10 personnes, donc voilà, il y a toujours un équilibre à trouver, mais l'idée, c'est vraiment d'aboutir à ce shared understanding, cette compréhension partagée. Donc, l'idée, ça va vraiment être d'avoir... Donc, qui sont les 3 Amigos dans la théorie ? On a le PO qui vient présenter son besoin, on a le dev qui vient apporter la valeur plus faisabilité technique, et le testeur qui est, lui, pour le coup, plus le garant de la connaissance détaillée du produit, etc., et qui va avoir souvent des questions du genre, ah oui, mais est-ce qu'il est à penser au cas où, etc., machin. Attention, je mets un warning aussi, c'est qu'en gros, ce n'est pas parce que vous n'avez pas de testeur dans une équipe, c'est très courant, que vous ne pouvez pas faire de BDD. Quand on met le ou plus, c'est toutes les personnes qui sont concernées, ça peut être un designer, ça peut être un marketeur, ça peut être tout le monde. Et l'idée de cette réunion des 3 Amigos, c'est, je le redis, sortir de la réunion avec une compréhension partagée, un alignement de tout le monde pour que la suite soit plus fluide, et des critères d'acceptation ou carrément des tests d'acceptation qui, justement, permettent de mettre le doigt sur ce qui a de la valeur, en fait, pour le PO. Et c'est ces tests d'acceptation qui vont être à l'origine du contrat entre le PO et le développeur. Donc, on n'a vu pas de BDD sans collaboration, et un des éléments phares aussi du BDD, c'est les exemples concrets. Si je reprends, par exemple, la définition en intuite de Daniel North, enfin, Dan North, de qu'est-ce que c'est le BDD, il commence même par le fait de dire « using examples ». Donc, vraiment, utiliser des exemples à tous les niveaux pour faire en sorte qu'on ait une compréhension partagée et qu'on puisse délivrer des softwares, enfin, des logiciels qui comptent, ou qui ont de la valeur, quoi. Petite illustration. C'est basique, mais j'aime bien. En gros, voilà, vous avez l'impression de vous comprendre sur la gauche, et pourtant, il y en a un qui dit « bah non, en fait, là, c'est un 6, non, non, c'est un 9 ». En fait, ils ne sont pas d'accord, et discuter des choses, ça permet justement de lever les ambiguïtés, quoi. L'image du milieu, elle est peut-être un peu plus touchy. Je ne sais pas parmi vous, on n'est pas nombreux, mais qui est-ce qui voit la face A en avant ? Ok, tout le monde, très bien. Moi aussi, j'ai cette tendance-là. Est-ce que vous êtes capables de faire l'effort de renverser la tendance et de voir la face B en avant ? Voilà. Et pourquoi, en fait, alors ça, je ne saurais pas l'expliquer dans le détail, je sais, en tous les cas, pour ceux qui sont intéressés par ce genre de problématiques-là, lisez Albert Muqueber, ou écoutez-le, il fait des super vidéos aussi. Mais en gros, on manque d'informations pour savoir exactement si c'est la face A qui est devant ou la face B. Et du coup, finalement, les deux sont complètement possibles et personne n'a tort, en fait, dans cette histoire, parce qu'il manque de l'info. Et justement, ce genre de réunion, c'est aussi le moment de venir compléter des infos, de venir s'assurer que tout le monde parle le même langage et que quand on dit « on a atteint la cible », par exemple, que tout le monde soit d'accord sur qui c'est la cible, ou qu'est-ce que c'est la cible, ou qu'est-ce que c'est l'objectif, etc. Et le petit dernier que j'aime bien aussi, c'est qu'en gros, j'imagine que vous avez commencé à vous poser la question de « est-ce que c'est plutôt un B ou est-ce que c'est plutôt un 13 ? » Finalement, ça peut être les deux, pareil. D'autres peuvent complètement voir autre chose. Un logo d'une marque dont je tairai le nom sur une barre, par exemple, au renversé. L'idée, en tous les cas, vous l'avez compris, c'est vraiment de s'aligner. Et c'est les exemples qui vont servir à ça. Une toute petite, rapide mise en situation. Si on a une fonctionnalité qui est de dire, par exemple, qu'on veut ajouter les frais de livraison au prix total du panier. Quand on le dit comme ça, on se dit « oui, c'est clair, c'est évident, on ajoute les frais de livraison ». Avec des règles en plus. Pour les paniers de moins de 30 euros, les frais sont de 6 euros. Et pour les paniers de plus de 30 euros, les frais sont de 3 euros. Sur ces règles-là, très rapidement, vous, qu'est-ce que vous vous posez déjà comme question ? Oui ? Plus ou moins égal. Déjà, on est tous d'accord, il manque le égal. C'est volontaire et c'est grossier. Mais effectivement, qu'est-ce qui se passe si mon panier est pile égal à 30 euros ? Ce qui est complètement possible d'arriver. C'est gratuit. C'est gratuit, ça bug. Donc du coup, ça passe et on en reçoit 3. Mais qu'est-ce qu'on pourrait avoir comme autre question par rapport à ça ? Je ne peux pas vraiment vous donner plus de contexte, mais des trucs hyper classiques sur les e-shops ? Je ne sais pas. Les promotions. Exactement. Les promotions, comment on fait si on doit ajouter une promotion ? Est-ce que la promotion est prise dans le total des 30 euros ? Est-ce qu'elle n'est pas prise dans le total, etc. ? Et c'est très spécialement ce genre d'informations qu'on veut lever, en fait. Là, on n'a aucun contexte. Donc, j'ai pris un exemple vraiment de e-shopping qui parle à tout le monde. Mais effectivement, on est sur ça. L'idée, c'est vraiment... Du coup, c'est celui que j'ai pris comme exemple. Qu'est-ce qui se passe si je renseigne un code promo de 5 euros ? Est-ce que notre total, il est sur la base du total avant la promo ou après ? Et en fait, de donner des exemples, ça permet d'ancrer de manière sûre et certaine que l'information, oui, c'est ça. Et là, vous voyez, très rapidement, je n'ai pas mis la structure give and when then. Et pourtant, je fais du BDD. Parce que je collabore et je m'appuie sur des exemples qui lèvent les incertitudes et qui viennent ancrer. Je ne sais pas si vous avez déjà eu l'occasion, j'imagine, d'aller sur les sites publics, notamment des impôts, où on vous explique la règle pour bénéficier de quelque chose. Ils donnent des exemples tout le temps. Avec, généralement, la situation moyenne. Mais parce qu'en fait, s'ils ne donnent pas d'exemples, personne ne comprend rien. On n'arrive pas à se projeter. En fait, l'exemple, c'est vraiment la transition entre la règle un peu abstraite et la vraie vie, dans laquelle on se projette beaucoup plus facilement. Et cette projection-là dans la vraie vie, ça aide aussi à réfléchir plus loin. Et à se dire, attends, tu m'as dit le code promo, mais qu'est-ce qui se passe si le mec, en plus, il a une carte d'abonnement membre qui fait que de base, il a... et ainsi de suite. Donc voilà. Donc sans BDD, on ne discute pas au préalable. On se base sur l'aspect que va donner le PO, par exemple. On n'illustre pas d'exemple. OK, donc du coup, potentiellement, en cours de route, il va y avoir des incompréhensions. Le pire, c'est l'incompréhension qui passe inaperçue, puisqu'elle est développée et ensuite, si on a un testeur, il va dire, ben non, ce n'est pas ça qui était demandé. Le Dave va dire, ben si, ben non, ben si, on va aller demander au PO, qui va prendre du temps. En fait, ce qu'il faut voir, c'est que chaque personne prend du temps à chaque fois. Donc quand on est en cours de route, on perd beaucoup plus de temps que si on prend ce temps en amont, on aligne tout le monde. Et puis, au-delà de simplement aligner les gens, c'est-à-dire que quand il y a une question qui se pose, un développeur, il pourrait...
il répond tout seul sans avoir à solliciter son PO parce qu'il sait la logique dans laquelle il est en train de travailler. Et c'est vraiment ça qui est hyper intéressant dans le BDD. Je le disais tout à l'heure et je le redis là, mais pour le coup, ces exemples, qu'ils soient écrits en Gherkin ou pas, ça devient finalement un contrat entre le PO et les développeurs. Donc dans notre code spec, à la fin, on va mettre un critère ou un test d'acceptation et finalement on va mettre là les choses qui apportent le plus de valeur à la fonctionnalité et au produit du coup in fine. Et c'est le PO qui va être capable de dire ce qui apporte de la valeur et c'est le développeur qui va s'engager à faire en sorte que ce qui va livrer correspond à ce qui a été demandé. Donc vous voyez qu'il y a vraiment le côté très très collaboratif, c'est à dire qu'une équipe où le développeur fait du BDD tout seul, c'est pas du BDD. Et tout le reste est formalisme. Alors c'est peut-être un peu abusé de dire ça, mais bon j'aimais bien la formule et puis je me suis un peu inspirée pour ce qu'on reconnaît. Donc le formalisme, qu'est-ce que c'est ? On retrouve les scénarios Gherkin parce que l'idée c'est vraiment d'avoir du given-when-then, on reprend une structure où on vient prendre la cohérence de l'ensemble et on n'a pas un développeur qui parle en termes de tests écrits en langage machine, on n'a pas un testeur qui vient dire quand je clique sur le bouton puis je fais ça puis je remplis machin, c'est vraiment des éléments d'information compréhensible par un humain et comme on disait tout à l'heure qu'ils vont servir du coup de living documentation parce que du coup ça garde la trace de ce qu'on veut que les choses fassent. Et après le côté given-when-then et toutes les architectures qu'il y a autour parce qu'il y a d'autres mots clés, ça permet aussi d'avoir cette structure qui permet de systématiser un peu les choses et d'entrer dans l'état d'esprit de tiens là je suis dans une situation, de quoi je pars, qu'est-ce que je fais, où j'arrive. Alors je ne peux malheureusement pas pousser sur le comment écrire des scénarios Gherkin, mais voilà je suis ouverte après à en discuter autour d'un verre, juste un petit exemple rapide de ce que ça peut donner. Donc là en fait c'est tiré d'un exemple d'une vidéo de John Ferguson qui est un des chantres du BDD et en gros on voit qu'on peut aller très loin. Là on a un scénario outline, on peut mettre des variables qui ensuite sont reprises dans des tableaux qui eux-mêmes peuvent être pris dans des examples. Donc la structure pipe c'est vraiment pour pour gagner du temps et gagner du test quoi, enfin du test, du scénario. Ce qu'il faut comprendre aussi c'est que du coup sur ce côté, écrire les scénarios Gherkin en given when then, c'est bien pour être compris par un humain, ça aligne tout le monde etc, on sait où on va, mais ça n'en fait pas pour autant des tests automatisés. Et donc on parle beaucoup de spec exécutable, mais pour être exécutable il y a la partie spec, c'est le scénario Gherkin et derrière il y a un travail du coup de la part du développeur de traduire ces scénarios Gherkin en tests exécutables par une machine. Et donc du coup on va souvent avoir d'un côté, ce que j'ai mis là mais j'ai un autre exemple, d'un côté on va avoir dans notre repo des fichiers .feature et ailleurs dans le code on va avoir d'autres fichiers qui reprennent généralement le même nom et qui s'appellent steps ou stepdef ou stepdefinition ou peu importe, il y a du moment qu'on reste cohérent avec l'extension du type de fichier. Et on voit du coup ici qu'il y a vraiment cette expression là en Gherkin qui permet de garder ce côté living documentation à laquelle n'importe qui, n'importe quel humain comprend ce qui se passe et qui est, chaque ligne est ensuite traduite par les développeurs puisque c'est eux qui savent par les machines qui s'arrangent pour traduire chaque ligne en quelque chose d'exécutable. Et leur enjeu, je spoil un peu, ça va être de faire en sorte qu'on ait des steps qui soient réutilisables en fait pour limiter en fait, pour faciliter la maintenance même pour être très exact. Donc si je reprends le process complet, donc désolé j'ai pas pu agrandir plus, ça devenait trop flou, mais l'idée c'est vraiment on a notre PO qui va faire sa discovery, qui fait son travail en amont. Une fois qu'il a quelque chose de satisfaisant ou qu'il a envie d'avoir le conseil de ses pairs, enfin de ses pairs non, de l'équipe, il vient faire sa réunion des trois amigos de laquelle sort un share d'understanding, donc une compréhension commune et des tests d'acceptation. Et à partir de ça, le développeur va du coup créer le code, écrire les tests automatisés qui correspondent aux scénarios. Et ce qui est intéressant ici, c'est que quand vous avez un testeur, je le lis parce que vraiment je trouve que ça met bien les idées en place, le testeur utilise ces scénarios comme une base pour ses tests. C'est à dire que ce n'est pas au testeur ou au QA d'écrire les scénarios Gherkin, ce n'est pas à lui de les jouer, ce n'est pas à lui de les automatiser, ça lui sert de base pour ses propres tests. C'est à dire qu'il va s'inspirer de ça, il peut faire deux trois vérifications, mais les vérifications elles ont déjà été faites par le développeur puisque lui a automatisé les tests. Donc quand vous avez un QA, il vient en complément de ça et il vient enrichir et pousser plus loin votre qualité produit. Et ensuite, tac, vous poussez le produit parfait qui convainc tous vos utilisateurs. Alors, c'est un dessin de mon cru, je pense que vous le remarquez. Tout ça pour dire que voilà, c'est un peu une image pour rappeler cette fameuse image de l'iceberg. Souvent quand on pense BDD, on pense tous Gherkin, mais en fait non, Gherkin, c'est juste la face émergée de l'iceberg. Le vrai cœur du BDD, c'est cette réunion des trois amigos qui sacralise la collaboration au sein de l'équipe. Les exemples, le fait de parler, de faire l'effort d'avoir un langage commun, c'est aussi des tests automatisés, ça reste au final la documentation vivante et c'est beaucoup beaucoup plus large que simplement écrire des scénarios Gherkin. Et je le redis, si vous écrivez du Given When Then, vous n'êtes pas forcément BDD, vous ne faites pas forcément du BDD, mais simplement, un peu comme les agilistes qui utilisent des post-it, peut-être que vous utilisez juste des post-it. Comment ça se passe au niveau de la mise en place concrète et les outils ? Donc là, je vais aller relativement vite parce que ça, c'est plus des problématiques. Mon idée, c'est de vous donner le panorama, parce que vous allez entendre plein d'outils, de machins de trucs, comment ils se positionnent en fait. Donc pour ça, je repars du flow BDD que propose John Ferguson toujours et que je trouve assez parlant. On retrouve cette phase d'illustrer les choses où finalement, on vient parler en langage français dans cette réunion des trois amigos, on vient dire voilà comment ça doit se passer, j'illustre avec mes exemples. Les exemples sont formulés ou traduits en Gherkin d'abord. Donc Given When Then est donc mis dans des points features par le PO, non idéalement, ou le QA, ça dépend des organisations, du temps que vous avez, de machins. Mais en tous les cas, ce n'est pas le travail du développeur. Ensuite, le développeur lui, il va automatiser ses tests. Donc comme on l'a vu tout à l'heure, il va faire la partie step definition qui correspond au point feature. Il va créer le code, puisque là, visiblement, on est dans vraiment un TDD fort. Donc il va créer le code. Donc il a ses tests, il crée le code qui correspond à ses tests et qui les fait passer vers. Et ensuite, il vient démontrer au PO qu'il a rempli sa part du contrat et ainsi de suite. Donc si je reprends les étapes, donc je vais les reprendre, excepté create, puisque ça c'est juste écrire du code, mais je vais les reprendre une par une. Effectivement, je ne sais pas moi-même écrire du code, j'ai beaucoup de respect pour les développeurs. Donc la partie illustrée, on va retrouver des outils qui sont moins des outils comme on peut avoir l'habitude des applications ou des logiciels, mais vraiment ça peut être simplement des méthodes de travail. On retrouve évidemment l'example mapping avec ses règles, ses process, ses machins. Donc voilà, si vous ne connaissez pas ces ateliers-là, je vous invite à aller creuser un petit peu. Mais de toute façon, tout est dans le nom. L'idée, c'est vraiment de réussir à pondre des exemples à partir de la règle. Le feature mapping aussi, qui est une approche un peu différente, mais qui est complémentaire. Et l'event storming. Et tous ces ateliers-là, finalement, peu importe, ça peut être complètement du fait maison. L'important, c'est que vous collaboriez entre du PO jusqu'au dev et le QA, si vous en avez un, et les marketeux et tout le monde. Que tout le monde partage une même compréhension du besoin. Et qu'on ait fait ce travail de réflexion collective. Donc prenez les outils que vous voulez, et les méthodes que vous voulez, celles qui vous conviennent le mieux, mais communiquez. Pour la partie plus formulée et automatisée, je les ai regroupées ensemble, parce que souvent on va avoir des frameworks qui sont dédiés à ces deux parties. Le plus connu, évidemment, c'est Cucumber, qui couvre beaucoup de langages. Un autre très très connu, c'est BIAT. Parce qu'en fait, c'est officiellement la version Cucumber, mais en PHP. Ils sont nés en même temps, et du coup, Cucumber n'avait aucune raison de revenir sur un truc qui marchait déjà très bien et qui était très bien maintenu par une communauté.
fiable. Un peu différent personnellement, je n'ai jamais utilisé, ça va être jasmin mais qui s'attache juste au JS, jbave on l'a vu tout à l'heure qui s'adresse au Java et puis on va avoir specflow, pareil qui est la version .net officielle pour Cucumber etc etc. Et alors que font ces outils ? Justement en fait ils permettent de, alors je n'ai pas remis l'image, mais on a vu tout à l'heure les points features d'un côté et les stepdef de l'autre, finalement ils font le lien entre ces infos là à votre place pour que ça soit un minimum fluide. Ensuite on a la partie donc le développeur il y code et ensuite une fois que tous ces tests sont verts, il vient démontrer à son PO qu'il a fait le travail et pour ça on va avoir plus des plateformes un peu plus high level on va dire et dont l'objectif c'est vraiment de rendre du visuel de suivi et les deux outils les plus connus pour ça ça va être Cucumber Studio donc une extension de Cucumber et Serenity BDD qui est porté par John Ferguson. Donc vous voyez le côté ici on est capable en tant que PO, en tant que chef de projet, en tant que peu importe ce que vous avez dans votre équipe d'avoir un peu une idée de ce qui se passe. Si on voit que tout est rouge, il y a des chances qu'on ne donne pas le... qu'on ne mette pas en prod quoi et qu'on demande des comptes peut-être aux devs mais voilà. Là je vais aborder plus la phase un peu finalement critique du BDD avec vraiment les deux parties, la partie où finalement le BDD il est populaire et popularisé mais un peu maltraité parce qu'incompris, la partie des vraies limites. Donc par rapport au fait que le BDD devienne de plus en plus d'ailleurs populaire finalement pourquoi il est maltraité c'est parce que sur internet vous trouvez vraiment vraiment vraiment beaucoup de ressources et vraiment vraiment vraiment beaucoup de ressources qui sont pas bonnes. Quand je dis pas bonnes c'est vraiment par rapport au fait que quand vous n'y connaissez rien si vous allez de manière random prendre des infos ben en fait vous allez comprendre un premier truc et finalement vous allez lire quelqu'un d'autre qui dira complètement l'inverse ou des trucs pas cohérents et puis quelqu'un d'autre qui dira encore autre chose et puis vous aurez l'impression à un moment d'avoir compris et puis finalement non ça sera cassé. Alors je dis ça évidemment en connaissance de cause puisque je l'ai vécu il y a un peu longtemps maintenant mais voilà et typiquement je vous ai pris vraiment deux exemples qui pour moi m'ont vraiment marqué mais typiquement la personne qui a écrit cet article là alors les articles par ailleurs sont intéressants donc c'est ça il faut savoir aussi être critique à l'intérieur de ce que vous lisez mais en fait le TDD effectivement on a le côté écrire un test unitaire qui faille, on fait en sorte que le test passe en écrivant le code qui correspond, on refactore si besoin etc et donc du coup sans doute j'imagine par beauté de l'image la personne a reproduit exactement la même chose pour le TDD avec ce truc incompréhensible qui est d'écrire un test d'acceptation qui échoue pour ensuite écrire un test unitaire qui échoue, refactoriser son test d'acceptation, enfin ça n'a aucun sens, vraiment il y a une logique si on reprend de la hauteur c'est de dire que finalement les tests d'acceptation viennent alimenter les tests unitaires mais toute cette boucle là elle est fausse à aucun moment on va chercher à faire échouer un test d'acceptation, le PO ne va pas dire ah ah je t'ai fait tester ça mais en fait c'est pas ça que je voulais je voulais juste voir si tu étais attentif quoi, ça ça n'arrive pas dans la vraie vie donc voilà cette partie là est fausse, cette partie là est complètement correcte, ce qu'il faudrait faire ce serait simplement dire writing an acceptance test donc écrire un test d'acceptation qui vient alimenter un test unitaire qui va d'abord fail et voilà et puis c'est tout quoi, on enlève cette partie basse et on enlève le failing, je m'éternise un peu mais c'est pardon c'est et ensuite sur pareil cet article là c'est un des premiers que moi j'ai consulté et j'ai lu ça je me suis dit ok bon et on lit écrire de bons BDD si vous avez un peu suivi tout ce que je viens d'expliquer donc le BDD c'est une méthode c'est à dire que là on pourrait enfin si on devait transposer ça serait comme écrire écrire de bons agiles ou de bons agilités ça n'a aucun sens par ailleurs l'article est intéressant il donne des bons exemples etc l'idée c'est pas de pointer du doigt dire c'est nul c'est vraiment de mettre l'accent sur le fait que quand vous lisez des choses sur internet restez très très critiques et voilà et pareil premier truc qui est traduit utilise des outils BDD business driven development alors c'est pas tout à fait beau puisqu'on se concentre sur la valeur produit qui au final est du business mais ça fait pas très propre de mettre une erreur dès la première lignée en fait et voilà et ce n'est pas si simple d'écrire du BDD bah non ce n'est pas si simple d'écrire de l'agile ça ça n'a aucun sens quoi par contre on pourrait écrire ce n'est pas si simple d'écrire des scénarios gherkins parce que ça oui ça c'est vrai c'est correct et effectivement c'est pas si simple d'écrire des scénarios gherkins bon deuxième maltraitance bah c'est que souvent c'est un travail qui est laissé à la charge des développeurs et vous l'avez compris c'est la collaboration au coeur donc c'est comme enfin une fois de plus un transposé agile est-ce que vous imagineriez une seconde que ce soit des développeurs dans l'équipe qui soit les seuls à travailler en scrum par exemple bah non ça c'est l'essence de l'agilité c'est de faire collaborer les gens donc du coup c'est un peu cette idée là quoi donc oui les développeurs écrivent la partie qui les concerne c'est la part la partie automatisation des tests mais par contre ils n'écrivent pas les scénarios gherkins ils peuvent éventuellement y participer puisque dans le cadre de la réunion ils donnent des exemples et ils participent aux exemples mais on n'attend pas d'eux qu'ils écrivent la partie gherkin de ces scénarios. Et ensuite à proprement parler dans la rédaction des scénarios en gherkin il y a beaucoup beaucoup beaucoup d'erreurs alors le premier on dirait pas qu'il a des erreurs et pourtant un de ses problèmes c'est qu'il n'a pas un seul centre d'intérêt un seul single concerne quoi donc là et puis même il est un peu trop trop précis et peut-être aussi qu'il sert à rien mais ça ça va dépendre de votre de votre contexte et celui là je pense que vraiment c'est en gros faire la somme enfin faire la somme de deux chiffres quand on ajoute 1 à 2 il faut que ça fasse 3 à moins que vous soyez en train de développer une calculette je suis pas sûre que ça ça ait de la valeur métier en fait je voilà revenez toujours à ça c'est mon scénario c'est pas un test c'est quelque chose qui vient dire c'est ça qui apporte de la valeur à mon produit et donc du coup quand je dis que c'est pas des tests ça veut dire que ça il faudra le tester mais c'est pas du ressort du c'est pas la valeur du produit quoi donc astuce 1 d'abord c'est la seule chose que je puisse vous conseiller c'est de vous abreuver aux bonnes sources et on l'a vu de rester critique qu'est ce que c'est les bonnes sources finalement c'est les gens qui ont inventé le truc et ce qui est encore plus intéressant je vous ai pas mis le lien mais l'iskeog a fait en fait ce qui est intéressant aussi c'est qu'on voit l'évolution même de leur propre pensée c'est à dire comment ils réajustent les choses etc et il y a vraiment ce côté feedback et historique et de dire mince on a fait comme ça mais on s'est trompé et voilà pourquoi on s'est trompé ça c'est hyper intéressant la doc de coucou meurt forcément elle est très bonne et voilà alors c'est que des des américains peut-être des anglais aussi d'ailleurs je sais pas mais bref il n'y a pas de français là dedans mais peut-être un jour on ne sait pas ou alors peut-être juste que je les connais pas mais je suis preneuse des noms donc voilà astuce 2 aussi bas c'est simplement faites-le quoi jetez-vous à l'eau et faites-vous votre propre expérience parce que finalement bas le bdd c'est la collaboration avant tout mais autour d'un produit avec une équipe et des gens et des enjeux différents et donc du coup bas c'est en faisant qu'on devient forgeron et en forgeant qu'on devient forgeron et du coup je vous ai mis en lien cette vidéo là de vincent prêtre alors pour info vincent prêtre il travaille chez hip test et hip test ça a été racheté par coucou meurt studio en fait je sais c'est devenu coucou meurt ça a été racheté par coucou meurt et c'est devenu coucou meurt studio et donc du coup je pense que s'il y a bien quelqu'un qui s'y connaît c'est lui et ce qui est super intéressant dans son rex bas c'est qu'en fait il montre comment au début ils se sont plantés en fait et c'est pour ça que je le mets dans cette partie là c'est n'ayez pas peur de vous planter et puis allez-y et puis faites vous vos propres expériences quoi et sur la partie plus limite de la méthode bah du coup une des premières limites ou une des premières difficultés on va dire là c'est que finalement il faut réussir à trouver l'équilibre entre d'un côté ces fameux ces fameux confitures les scénarios en guerquines et leur traduction en test automatisé parce qu'en fait ça paraît simple comme ça dans la théorie on dit ben j'ai un step je le traduis ouais mais en fait il ya derrière un step il ya plus que simplement un step il faut lancer son serveur il faut s'assurer qu'on est sur le bon environnement il faut que ceci faut que cela il faut s'assurer qu'on est dans les bonnes conditions et donc du coup alors je vous invite pas à lire ça un peu ce que vous lirez quand vous aurez la presse
Ce sera plus simple, mais l'idée de ce petit article, c'est de dire qu'en gros il faut trouver l'équilibre entre d'un côté des scénarios Gherkin, qui reste lisible pour un humain, mais quand même suffisamment précis, donc pas trop high level, pour que les développeurs ne soient pas en galère à les automatiser en fait. Vraiment, on est dans la collaboration du début à la fin. Une autre limite, et qu'il faut garder en tête, c'est qu'utiliser Cucumber ou utiliser les frameworks de tests en BDD, c'est contraignant pour les développeurs. Pourquoi c'est contraignant ? Je ne l'imponte pas, c'est un retour d'expérience que j'ai eu d'un développeur et je ne saurais pas le développer dans l'absolu. Mais de ce que j'ai compris en tout cas, c'est que contrairement à leurs outils de tests classiques, ils ont des contraintes qui font qu'ils ne sont pas totalement libres de faire tout ce qu'ils veulent, et ils sont obligés d'épouser les conventions des frameworks. Et donc du coup, si vous voulez mettre en place du BDD dans votre équipe, et que c'est que les développeurs qui le font, à la limite, ne l'en faites pas, faites en sorte qu'ils puissent faire des tests automatisés avec leurs outils classiques, ils seront beaucoup plus à l'aise et beaucoup plus confort, si vous voulez mettre en place du BDD, c'est vraiment toute l'équipe. Et une autre petite contrainte, mais ça c'est vraiment du côté des développeurs, c'est ce que j'ai déjà dit aussi tout à l'heure, un des enjeux c'est de réussir à avoir des tests, enfin des test-steps, qui soient réutilisables, parce qu'en fait finalement, dans un scénario on va toujours retrouver certains points d'entrée qui vont être les mêmes. Et en fait, plutôt que de réinventer la roue à chaque fois, il faut bien découper et bien automatiser ça. Pour la partie, ça c'est pareil, c'est un peu, enfin pas une opposition, mais une friction de deux approches. La règle dans les scénarios Gherkin, c'est de dire qu'il ne faut mettre que l'information qui compte, parce qu'on veut rester lisible, on veut rester compréhensible, et on ne veut pas venir perturber la compréhension par des infos qui ne sont pas importantes. De l'autre côté, quand on veut concrétiser un test, il faut avoir ces informations, parce que sinon le test ne passe pas. Si je donne un exemple, imaginons, on peut souscrire une assurance, et si on est une femme, non on va dire, si on a moins de 18 ans, non ça ne marche pas, je ne veux pas être sexiste, mais si on est une femme, pas sexiste dans le bon sens, si on est une femme, on a une réduction de 20% parce que statistiquement on fait moins d'accidents, si on est un homme, on n'a pas de réduction de 20%. Ok, donc du coup, ce qui compte ici, ça va être la différenciation sur le sexe. Est-ce que je suis un homme ou est-ce que je suis une femme ? Si je suis une femme, j'ai une réduction de 20%. Si je suis une femme, je souscris, alors j'ai une réduction de 20%. Je suis un homme, je souscris, je n'ai pas de réduction de 20%, basiquement. Sauf qu'en réalité, ça c'est le scénario Gherkin, il est bien, il est clair, il est compréhensible. Pour que le test passe, il y a une règle supplémentaire, qui est qu'il faut avoir plus de 18 ans. Et donc du coup, pour que le test passe, c'est pas juste je suis un homme ou je suis une femme, c'est plus, j'ai plus de 18 ans à chaque fois. Donc voilà, c'est un des exemples pour montrer aussi que parfois, il faut connaître un peu mieux son application pour faire passer le test à proprement parler. Un autre petit point, c'est qu'en fait, et ça c'est d'ailleurs complètement assumé par les promoteurs du BDD et des scénarios Gherkin, c'est qu'en fait, le BDD, c'est là pour illustrer les règles métiers. Et donc, ça couvre mal les parcours utilisateurs. Et pour comprendre ça, c'est assez simple. Moi, je le vois vraiment comme une loi, par exemple. Une loi qui dit, un mineur n'a pas le droit de rentrer en boîte de nuit, on n'a pas besoin d'avoir une implémentation concrète. Peu importe la boîte de nuit, t'as moins de 18 ans, tu ne rentres pas, t'as plus que 18 ans ou égal 18 ans, tu rentres. Et en fait, on n'est pas en train de dire, alors la personne se présente devant la boîte de nuit, le videur est en train de contrôler son âge, puis parce qu'il a plus que 18 ans, il peut rentrer, etc., il va boire un verre, etc. Et c'est vraiment cette idée-là de les scénarios, les exemples finalement, ils sont là pour illustrer une règle et pas forcément, pas pour illustrer un parcours. Et il y a une petite mise à jour, c'est justement proposé par Seb Rose dans Formulation, qui propose des journées scénarios, mais lui-même, il met un bémol en disant, attention, il ne faut pas les utiliser à outrance. C'est avant tout illustrer une règle. Et un moyen mnémotechnique pour se souvenir de ça, c'est en fait de se dire, tous les exemples, on doit être capable de les présenter dans la réunion des trois amigos, c'est-à-dire à un moment où on ne sait pas à quoi va ressembler notre produit. Donc, ce n'est pas la peine de venir dire, oui, il cliquera sur tel bouton et puis il fera ça, il fera ça, et puis il arrivera à tel endroit, puisqu'on ne le sait pas encore. Par contre, être capable de dire qu'on a une réduction si on est une femme et pas de réduction si on n'est pas une femme, ça, on le sait en amont parce que c'est le travail, c'est la règle métier fournie par le PO. Enfin, peut-être une dernière limite, c'est plus sur la maintenance et la lisibilité. On parle beaucoup de living documentation. En réalité, quand il y en a beaucoup des scénarios, ça devient vite imbitable. Donc, il faut aussi réussir à soit les organiser mieux, donc découper, enfin, il y a des vrais enjeux autour du découpage des features, des points features, et ensuite autour de la maintenance des scénarios, même en given, en gerkin, pardon, et ensuite, forcément, sur l'automatisation, la partie automatisation. OK, l'heure, il est, c'est bon. Et enfin, bon, ça, c'est ma petite touche à moi parce que je suis testeuse, mais BDD, c'est pas tester. Donc, j'ai mis entre guillemets parce que BDD n'est pas un verbe. Mais BDD, je le redis, l'idée, c'est vraiment de mettre l'accent sur ce qui va être important. Et un test d'acceptation, un critère d'acceptation, c'est qu'est-ce qui fait que pour le PO, on va remplir le contrat ou pas. Pour autant, à côté de ça, il va y avoir d'autres tests à faire parce que, en fonction de vos enjeux de qualité, etc., simplement, ça ne bloquera pas forcément la mise en prod, sauf à trouver quelque chose de vraiment bloquant que personne n'aura réussi à anticiper. Mais l'idée, c'est vraiment, avec le BDD, d'anticiper au maximum. Mais c'est vraiment, le BDD, pour moi, c'est ce que j'appelle le minimum légal de la qualité. C'est-à-dire que si tu n'as pas ça, c'est compliqué de dire oui, on va en prod. Mais si tu l'as, parfois, ça peut ne pas être suffisant et il peut y avoir d'autres problèmes, soit des edge cases, soit des cas que personne n'a jamais vus et qui semblent évidents, soit des cas aux limites, enfin, tout ce qu'on veut. Et d'ailleurs, je ne suis évidemment pas seule à dire ça, mais si je reprends un exemple, je vous évite de tout lire, mais l'idée, c'est vraiment, le BDD, ce n'est pas une activité de qualité. Ça n'a pas vocation à remplacer les autres formes de testing. Donc, une fois de plus, c'est le minimum légal de la qualité. Vous pouvez faire du BDD et avoir un QA, ça a complètement du sens. Conclusion. C'est très long, j'espère que je ne vous endors pas. Mais en gros, la conclusion, si on doit revenir, vous l'avez compris, l'essence, c'est la collaboration. Le BDD ne remplace pas les tests. Par contre, ce n'est pas non plus un étage des tests. Pour ceux qui connaissent la pyramide, je ne m'éternise pas dessus, parce qu'on peut faire une presse de deux heures rien que sur la pyramide des tests. Mais en gros, l'idée, c'est vraiment de se dire, c'est à tous les étages. Et l'idée, c'est qu'une fois de plus, ça représente ce qui apporte de la valeur à notre produit, ce qui est vraiment l'essentiel de l'essentiel. Et s'il y a un test en BDD qui pète sur une mise en prod, ou avant une mise en prod, il faut impérativement le corriger. Je reprends cette image, j'ai reprise du rex de Vincent Prêtre. Et chez eux, par exemple, il me disait qu'ils ont 500 tests en BDD, 1200 tests de service, service ou intégration API, vous mettez ce que vous voulez derrière, et 4000 tests unitaires, donc plus BAC généralement. Donc, vous voyez un peu la proportion. Voilà. On en a vraiment beaucoup en BAC unitaires, un peu moins en intégration, et le test BDD, on est sur vraiment la valeur métier, ce qui va apporter de la valeur à votre produit. Et je reprends, juste en termes de conclusion aussi, donc c'est Seb Grose qui disait, en gros, le BDD n'est pas une activité de QA, blablabli, blablabla, et que, eux, ce qu'ils ont constaté, c'est que dans les équipes où ils mettent en place du BDD, ils constatent une meilleure qualité quand même, et un déploiement qui est moins cher, qui revient moins cher. Donc à la fois, un meilleur coût, et un meilleur produit. Donc la qualité ne coûte pas forcément. Et enfin, vraiment le tout dernier mot, c'est qu'en gros, le BDD, finalement, ça s'inscrit dans ce qu'on appelle le shift left, ou shift left testing, qui finalement est un mouvement où, historiquement, on avait la phase de design, la phase de développement, et la phase de test. En fait, l'idée, c'est de ne plus avoir ce goulet d'étranglement de la phase de test, et de remonter le plus en amont possible les tests pour faire en sorte qu'on teste au plus tôt. Et tester en plus tôt, ça veut dire communiquer, ça veut dire faire du TDD, ça veut dire avoir un testeur qui vient alerter au plus tôt, etc.
toute une série de techniques qui permettent de casser ce goulet d'étranglement et de passer à quelque chose où finalement, quand on met en prod, on a anticipé et dérisqué au maximum. Ça ne veut pas dire qu'en prod, vous n'aurez pas de problème, ça ne veut pas dire qu'en phase, si vous avez une QA, qu'ils ne trouveront pas de bug, mais ça veut dire que les plus gros seront épurés. Et ça veut aussi dire quand vous en avez des QA plus heureux, parce que c'est quand même plus valorisant de partir à la chasse aux bugs que de simplement checker que le collègue développeur a bien écrit tel truc à tel endroit, fait ci, fait cela. Ça, c'est automatisé et on libère la créativité, l'inventivité, l'apprentissage du QA qui, du coup, fait un travail vraiment intéressant et pas juste un check. Au niveau des ressources, il y a les incontournables, notamment BDD in action. Il y a une deuxième version qui est sortie il n'y a pas très longtemps. Formulation de Seb Rose pour vraiment plus le côté très pratique, comment écrire ces scénarios. Un livre que j'aime bien aussi, c'est de Gojko Adjix, alors je ne sais pas comment on le prononce, c'est Specification by Example. Pourquoi ? Parce que finalement, ça comprend l'idée, ce n'est pas forcément de rester sur du given when then, du gerkin, donner des exemples. Si déjà vous faites ça, vous avez épuré, je ne vais pas dire de pourcentage, mais beaucoup d'incompréhension. Et voilà, writing a great specification, pareil, c'est ce côté. Et d'ailleurs, on voit bien via les lectures que le BDD, c'est beaucoup de la spec, une problématique de spec, donc plutôt de PO. Les ressources internet, je ne suis pas la pro de mettre toutes mes sources, mais voilà, je vous ai mis les basiques. Et puis, merci pour votre attention, j'espère que ça vous a plu. Et si vous voulez continuer à échanger, j'ai une adresse mail, j'ai un LinkedIn, et j'ai un site qui va bientôt être en cours de construction parce que je fais de l'accompagnement justement à la structuration des équipes autour de la qualité, donc BDD beaucoup, mais shift left de manière générale. Voilà, je ne sais pas s'il y a quelque chose encore après... Voilà, les questions et les réponses.