Les 6 clés pour rater son BDD
Le Behavior Driven Development, dans sa forme littérale, exprime une façon de travailler où le développement du produit est guidé par le comportement (« Behavior ») et donc centré sur l’utilisateur.
Le but est de diminuer ces fameux allers-retours entre le métier et l’équipe de développement. Un seul mot d’ordre: Discuter pour définir ensemble une seule et même compréhension du besoin.
Afin de vous aider dans ce sens, je vous propose de parcourir certains points qui vous amèneront à le rater.
1 — Rester centré sur le COMMENT (Déclaratif) et moins sur le QUOI (Impératif)
Il arrive que les scénarios gherkin soient écrits sous forme de tests plutôt que de spécifications métier, ce qui peut les conduire à être dénués de valeur métier et difficilement maintenables.
On tend à penser qu’il est nécessaire de décrire l’ensemble des actions que l’utilisateur doit effectuer sur l’interface utilisateur. Toutefois dans l’approche BDD, c’est l’objectif métier qui importe au-delà de la façon dont il est implémenté.
En résumé, écrire « ce que l’on fait » plutôt que « comment on le fait », évitera les détails superflus et sans réelle valeur métier. Il est donc important de définir le bon niveau de détail afin de pouvoir automatiser le scénario, d’où la nécessité de le définir lors des réunions 3 amigos.
2 — Faire du BDD sans Product Owner
Il y a potentiellement autant de manières de comprendre un besoin qu’il y a de personnes dans une équipe. Dès lors, définir le besoin et les exigences sans Product Owner est vain, car on tend inévitablement vers une vision technique du besoin et on prend le risque de passer à côté de la véritable valeur métier.
D’ailleurs, aucun des 3 amigos ne devrait écrire les exigences sans les deux autres.
Les scénarios utilisateurs rédigés uniquement par un Product Owner peuvent ne pas être testables et automatisables en l’état et demander un re-travail de l’équipe pour être exploitable. Une fois modifiés par l’équipe, ils risquent d’être en déphasage avec la vision de départ du Product Owner . D’où l’importance d’avoir un Ingénieur QA dans ces échanges afin de challenger les aspects de validation, testabilité et d’automatisation .
3 — “On fait du Gherkin, on utilise cucumber, donc on fait du BDD !”
Ce raccourci semble très répandu. Il est possible de faire du BDD sans utiliser le gherkin et réciproquement. Incroyable, mais vrai ! Le BDD est avant toute chose, une manière de travailler, une méthode dont le cœur est la discussion . Et bien que Gherkin et cucumber est la même signification ils demeurent deux éléments bien distincts
Le langage Gherkin permet de formuler les critères d’acceptances pour chaque scénario utilisateur dans un formalisme simple et compréhensible de tous.
Il est possible d’utiliser d’autres langages tel que l’UML (Unified Modelling Langage) pour définir un processus métier et être automatisable via des solutions d’automatisation « no-code » ou « low-code ».
Cucumber est un des outils qui permet d’interpréter les scénarios gherkin en vue d’exécuter le bout de code associé. En utilisant Cucumber, décrire les critères d’acceptances d’une user story en gherkin revient à générer une spécification exécutable. Ainsi, plus besoin d’écrire des tests, car les user stories deviennent les tests.
Si tous les trois restent au service du métier, ils portent des finalités différentes !
4 — Garder les features files près du code
Si vous collaborez pour exprimer le comportement attendu du système, assurez- vous que cette expression du besoin ainsi que les critères d’acceptances soient accessibles par tous, PO inclu ! Écrire des tests automatisés c’est chouette, mais quel intérêt si seules les personnes tech peuvent y accéder et les comprendre ?
Ce serait dommage que le PO ou le métier ne puisse accéder et se référer au besoin conjointement défini. Vous obtiendrez probablement plus de retours et plus tôt en rendant accessibles les scénarios utilisateurs identifiés par l’équipe.
5 — BDD est une méthode pour l’automatisation des tests
Cette phrase est aussi fréquente que erronée !
Cette confusion vient sûrement du fait que très souvent, une des attentes secondaires de cette pratique est la validation des exigences par des tests automatisés. Cependant le BDD a été créé à la suite du TDD, pour justement faire abstraction de cette approche par le test et se concentrer non pas sur la solution apportée mais sur le besoin énoncé.
Contrairement aux tests, le BDD ne nécessite pas d’avoir déjà un produit développé. D’ailleurs faire du BDD sur du legacy est une perte de temps inestimable. Cela reviendrait à repenser le comportement attendu d’une solution existante.
Toutefois, pratiquer le BDD en implémentant des spécifications exécutables est un réel accélérateur pour la QA. L’ingénieur QA, impliqué plus tôt dans le processus, pourra challenger la testabilité des exigences et mettre en œuvre les ressources nécessaires dès le départ et en vue de tester efficacement . Vous n’aurez plus besoin de temps supplémentaire pour concevoir vos tests, car les spécifications sont les tests. Quant à l’automatisation, elle pourra être réalisée dans la continuité des développements et en vue de les valider.
6 — Écrire les scénarios utilisateurs, après le code
Un product Owner, un développeur et un QA engineer n’auront pas la même compréhension d’un besoin métier, ni la même façon de l’expliquer et de le restituer.
C’est pourquoi l’écriture des scénarios avant le code est un facteur clé de l’assurance qualité. Cela encourage les 3 amigos à s’impliquer dans la définition du comportement attendu du logiciel. Ainsi, les incertitudes et possibilités d’interprétation sont rapidement identifiées et traitées.
De plus, un code source qui n’a pas été conçu pour être testable dès le départ, rend son automatisation presque impossible. Résultat : une dette de test inestimable.
CONCLUSION
Bien suivre ces 6 clés largement pratiquées dans nos métiers, vous assure de prendre la voie lente alors que vous avez la possibilité de prendre l’autoroute du succès.
Pour entreprendre de livrer des produits de Qualité, le BDD est un recours incontournable. Il permet de développer une valeur métier et de mieux répondre aux attentes de vos utilisateurs.
Je vous invite donc à réfléchir sur les risques que l’on encourt à utiliser le BDD de manière précipitée, incomplète et confuse. Vous pourriez engendrer une dette technique inestimable.
co — authors : Raissi Zied, Prescilliaabsalon
