Blog de Bruno Orsier

Un article de Bruno Orsier    2 Commentaires

La réunion du CARA sur la rédaction de spécifications exécutables grâce au BDD (Behavior Driven Development) a été très intense. Merci aux nombreux participants pour cette soirée stimulante et aux camarades du CARA pour l’organisation ! J’ai le sentiment que tout le monde a pu gagner une compréhension plus concrète du BDD, et a pu appréhender l’aspect collaboratif de la rédaction de scénarios.

Les discussions ont certainement dérivé de l’objectif initial qui était d’explorer différentes manière d’écrire des spécifications exécutables, mais elles n’en ont pas moins été très intéressantes. Il y a eu trop d’échanges pour tout retracer dans un seul billet, donc ici je vais me concentrer sur l’un des aspects : pourquoi s’intéresser au BDD ?

En effet, certains participants ont pu être surpris par l’approche elle-même : en gros, pourquoi passer tant d’énergie à décrire des exemples alors que l’application pourrait très bien être décrite par des règles plus abstraites voire des formules mathématiques ? Le BDD, avec son caractère très verbeux, semble un effort inutile, et en tout cas ne paraît pas « faire gagner du temps« . Il y a eu des échanges assez vifs sur ce thème, et voici quelques éléments qui ressortent en faveur du BDD :

• le pouvoir des exemples est souvent sous-estimé. Je viens de parcourir le livre de Gojko Adzic 
  

  Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

              pour trouver des arguments complémentaires sur ce thème :

  • les exemples sont un medium de communication simple et naturel, nous les utilisons tout le temps, sans même nous en rendre compte.
  • les gens qui élaborent les règles métiers abstraites le font généralement à partir d’exemples, qui sont ensuite perdus. Les développeurs doivent souvent ré-inventer d’autres exemples pour comprendre ce qu’il faut faire, ou pour explorer les cas limites. Plus tard les testeurs vont également ré-inventer d’autres exemples. Pourquoi ne pas travailler sur des exemples explicites dès le départ, les partager et les faire vivre tout au long du projet ?
  • les exemples, tests et spécifications sont des notions fortement liées de la manière suivante :
    
    Par conséquent, les exemples devraient avoir leur place dans nos méthodes de travail.
  • en comparaisons avec les exigences ou spécifications abstraites, les exemples réalistes laissent beaucoup moins de place pour l’incompréhension.
  • les exemples réalistes nous forcent à penser plus concrètement, et nous évitent de laisser des choses de côté trop vite.
• les scénarios du BDD sont exécutables. On ne parle pas ici de tests fonctionnels sous la forme d’un document Word, mais de fichiers textes qui peuvent être joués automatiquement et  aussi souvent qu’on le souhaite (dans l’intégration continue, dans les tests exploratoires). Par conséquent cette approche favorise le feedback fréquent que l’on recherche dans une approche agile.
• les scénarios du BDD constituent des tests d’anti-régression.
• il y a des cas où le côté verbeux et détaillé est clairement un avantage, par exemple quand on travaille avec des équipes offshore avec lesquelles il est difficile de communiquer.
• une fois au point, les scénarios textuels du BDD peuvent être modifiés, complétés, enrichis directement par les gens du métier, sans avoir besoin de faire appel à un développeur (lequel reste indispensable pour écrire le « pont » initial avec le code de l’application testée).
• les scénarios du BDD sont compréhensibles par le Product Owner, et peuvent servir de preuve de la bonne réalisation de la fonctionnalité souhaitée.
• le BDD sert également à découvrir le modèle métier, à se mettre d’accord sur un langage commun. Souvent les professionnels d’un domaine utilisent des abus de langage : travailler en BDD permet de lever les ambiguïtés correspondantes. 

Pour moi, la raison initiale de mon intérêt pour le BDD est l’intérêt que d’autres professionnels y portent. Certains travaillent de plus en plus avec ces outils, et pour preuve récente on peut consulter les chiffres suivants sur ce billet de Christian Blavier :

Voici quelques métriques que je viens de réunir dans différents contextes :
- secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper
- secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d’une centaine de tests par an
- encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d’une semaine
- secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d’exp complet est disponible ici : http://usi2008.universite-du-si.com/WebcastArchi.aspx (session A10)
- secteur open source , octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home

De plus je constate que dans nos projets, l’incompréhension entre équipe et product owner reste source de gaspillages importants, et se traduit en « retravail » sur des histoires utilisateurs que tous pensaient honnêtement bien terminées. La raison : tout simplement des points qui paraissaient tellement évidents pour tous que personne n’en avait discuté les détails. Dans certains cas, se forcer à écrire des exemples du comportement attendu aurait fait dissipé instantanément l’incompréhension.

C’est pourquoi je suis motivé pour poursuivre l’exploration du BDD. Il reste bien sûr à gagner plus d’expérience pour comprendre quelle est la place de cet outil dans la réalisation d’un logiciel et comment il s’articule avec le reste (notamment avec les maquettes d’interfaces graphiques – un autre thème de discussion de la soirée), quand l’employer et quand ne pas l’employer. En tout cas le BDD apparaît comme un outil complémentaire, qui ne remplace peut-être rien d’existant, mais qui probablement peut éviter des erreurs d’incompréhension, et donc au final fera gagner du temps à l’échelle d’un projet.