Mener un projet est un travail difficile… Beaucoup d’enjeux, d’attentes et de contributeurs : développeurs, testeurs, représentants métier, CP, PO, scrum masters et j’en passe…
Comment nous assurer que toutes ces personnes se comprennent ?
Dans un premier temps, il faut établir un vocabulaire commun.
Idéalement, il faudrait que les intervenants non techniques aient quelques bases en développement ou connaissent le système.
A l’inverse, les développeurs doivent s’exprimer sans rentrer dans des détails techniques trop complexes, et aussi faire preuve d’empathie envers les utilisateurs et les parties prenantes.
Un image bien connue pour résumer tout ceci :
La méthodologie BDD
Behavior Driven Development est une méthode agile encourageant la collaboration entre développeurs, responsables qualité et intervenants non-techniques d’un projet.
Selon Wikipédia et d’autres sources, BDD a été conçu en 2003 par Dan North comme « une réponse au Test Driven Development ».
C’est vrai mais pas que : TDD apporte des avantages avant tout aux développeurs, BDD en apporte pour tous.
Un langage et un vocabulaire commun
BDD permet aux contributeurs d’échanger autour d’un vocabulaire compris de tous et d’un langage simple. Pour cela, on utilise un langage naturel baptisé Gherkin. Nous y reviendrons dans le détail.
Des spécifications expliquées par l’exemple
L’ensemble de ces phrases forment des scénarios. Ces scénarios décrivent une fonctionnalité, une partie de l’application. Ces scénarios enrichissent les règles métiers en y apportant des exemples plus concrets.
Scénario: Demander un café court à 40 centimes
Etant donné que j'ai inséré 40 centimes d'euros
Quand je demande un "café court sans sucre"
Alors la machine me remplit un gobelet de "café court sans sucre"
Et ne me rend pas de monnaieQui rédige les scénarios ? A quel moment ?
Pour que la méthodologie fonctionne, il est essentiel que les scénarios soient rédigés en réunion collective, avec un représentant de chaque fonction (dev – testeur – PO). On parle de réunions « 3 amigos« .
Ces ateliers peuvent durer de 15 à 45 minutes (en fonction de la taille et du nombre de users stories que vous souhaitez présenter) où :
- Le PO présente la user story à développer, en précisant les règles métiers
- Le testeur vérifie que le contenu de l’US est clair et testable
- Le dev vérifie aussi le contenu de l’US et s’il peut exploiter ces scénarios (ce sera le sujet du 3ème article)
Les règles sont revues ensemble et progressivement transformées en scénarios avec des exemples concrets.
Le cas échéant, les interlocuteurs rajoutent les scénarios qui manquent pour être sûr de couvrir toute la fonctionnalité.
Pourquoi tester ?
- Minimiser, éviter les régressions lorsque le code est modifié
- S’assurer que le code est sécurisé lorsque le système est utilisé dans des conditions anormales
- Mettre en évidence les erreurs de conception et de mise en oeuvre. Lorsqu’une partie de l’application est difficilement testable, un défaut de conception en est souvent la cause principale (cf. Legacy Refactoring)
Mais aussi : pour gagner du temps lors des phrases de recette. Les testeurs se concentreront bien plus sur les nouveaux développements plutôt que de contrôler l’existant et les régressions.
Et surtout, réduire la boucle de feedback, donc minimiser les allers-retours entre développeurs et testeurs (ticketing etc.) Une fois lancés en local ou dans une build d’intégration continue, les tests automatisés vous donnent un aperçu immédiat si une anomalie est détectée. (un test passera au rouge)
Bien aborder BDD et l’implémentation des scénarios
La mise en place de l’automatisation peut s’avérer coûteuse au départ.
Faîtes le travail progressivement. Cherchez dans un premier temps à mettre en place les ateliers de rédaction entre les interlocuteurs, le but étant principalement de fluidifier la communication et de faciliter la compréhension du besoin.
Références
Si ce sujet vous intéresse, vous pouvez vous rendre sur ces sites :
