Les dérives qui rendent le BDD inefficace

Le BDD peut beaucoup apporter

Comme vous le savez en lisant mes divers articles, je suis convaincu que le BDD est particulièrement efficace dans des environnements agiles.

Les gains potentiels (directs ou non) sont très nombreux. Je pense notamment à:

• Des livraisons plus rapides en évitant les aller-retours liés à des incompréhensions et en permettant moins de travail « superflux »
• Une meilleure qualité avec des livraisons qui correspondent plus à ce qui est attendu par les utilisateurs
• Une meilleure qualité des US avec l’assurance d’avoir une structure « complète »
• Une augmentation de l’esprit d’équipe avec des membres qui se connaissent mieux à force de collaborer
• Une plus grande satisfaction de l’équipe qui passe moins de temps sur du retravail

Cela semble être une solution miracle! Ce n’est malheureusement pas le cas. 🙁

Je suis persuadé que vous (ou une de vos connaissances) avez vécu une expérience où le BDD n’apportait aucun de ces gains… et générait, au contraire, bien des inconvénients.

La raison est simple, le BDD ne se décrète pas. Comme toute démarche (ou même tout outil), s’il est mal mis en place il ne fonctionne pas!

Dans cet article je vais vous présenter certains mauvaises pratiques que j’ai observées ces dernières années.

L’impact de certaines « mauvaises » pratiques dans l’implémentation du BDD

Les « mauvaises » pratiques liées au BDD les plus fréquentes que j’ai observé dans les différentes équipes sont:

Considérer que le BDD est juste de l’automatisation (souvent en Gherkin)

On perd ici ce qui fait pour moi l’essence du BDD. Je pense à la collaboration des différents acteurs pour se synchroniser sur un besoin. On peut automatiser des scénarios d’acceptation issus du BDD, mais c’est pour moi la cerise sur le gâteau.

Au final, avec cette approche, les gains que l’on peut observer sont ceux de l’automatisation ce qui n’apporte pas les avantages du shift left qu’apporte le BDD.

Proposer des scénarios d’acceptation écrits et conçus par un unique membre de l’équipe (souvent le PO ou un QA)

Cette dérive est un peu compliquée à trouver.

De manière générale elle permet d’améliorer la qualité des US car apporte des informations supplémentaires. Elle permet également d’avoir une meilleure compréhension de ces dernières.

Néanmoins cette pratique ne permet pas d’aller au bout des gains du BDD car il n’y a pas de collaboration et de confrontation des points de vue et visions. De même, cela ne permet pas d’améliorer l’esprit d’équipe ou même d’avoir une compréhension commune.

On est pour moi sur des spécifications pas l’exemple ce qui est assez bien mais pas autant que les promesses du BDD.

Ne pas écrire les scénarios d’acceptation

Le fait de ne pas proposer de scénarios d’acceptation (ou d’exemple) engendre de nombreux effets de bords. Si au premier abord on peut penser que cela fait gagner du temps. Les participants à la réunion ayant compris le comportement de l’US sans écrire ces scénarios. On s’aperçoit vite qu’au final on perd du temps car cette absence engendre de nouveaux besoins comme:

• la présence de toute l’équipe à la réunion
  • Les absents n’auront pas les exemples pour illustrer le comportement
  • La présence de toute l’équipe augmente la durée nécessaire à la revue de l’US
• l’obligation de commencer à travailler sur l’US rapidement après avoir fait la réunion pour ne pas « oublier » ce qui a été dit (les paroles s’envolent et les écrits restent).

Des tests non compréhensibles par tous les profils

Cette problématique est généralement observable dans des équipes qui travaillent sur un produit assez technique. Les scénarios d’acceptation conçus peuvent être trop technique et non compréhensible par certaines personnes de l’équipe ou par des personnes en dehors de l’équipe qui pourraient avoir besoin d’avoir ces scénarios pour faire des retours (notamment dans des contextes avec des adhérences entre équipes).

Cette dérive peut, dans certains cas, mener aux mêmes problématiques que l’absence de BDD avec des compréhensions variables en fonction des intervenants.

Le BDD d’une US fait en cours de sprint

Cette pratique permet d’éviter des aller-retours et d’améliorer la qualité de l’US mais à retardement. Faire les activités de revues et d’illustration du comportement avant le sprint permet de bien cerner ce qui doit être fait avant de s’engager à livrer.

Une problématique de cette analyse des US faite en cours de sprint est que l’on peut vite s’apercevoir que l’on ne pourra pas forcément tout faire. L’équipe se retrouve face à un dilemme: bien livrer mais en retard ou livrer à temps ? De même, cette analyse tardive fait remonter des questions tardivement et on peut se retrouver à perdre du temps en attendant des réponses de parties prenantes que l’équipe auraient du avoir avant de commencer à travailler sur l’US.

Considérer qu’utiliser le langage Gherkin c’est faire du BDD

On est ici sur une incompréhension totale du BDD. Le Gherkin est un moyen d’écrire des tests. Avoir des tests scriptés c’est (très) important mais cela n’est pas lié au BDD.

Si vous voulez en savoir plus j’ai écrit un article dédié sur ce sujet.

Conclusion

Le BDD peut beaucoup apporter s’il est bien compris et mis en place. Cependant, il existe de nombreuses dérives, souvent liées à une incompréhension, qui font que le BDD n’est pas efficace.

Au final, le BDD est comme l’Agile, si l’on veut que cela soit efficace il faut le comprendre et s’approprier ses principes avant de commencer à l’implémenter puis de pouvoir l’adapter à son contexte.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles