Vous avez dit BDD ?

A l’heure où l’Agile est de plus en plus considéré comme la norme dans le développement logiciel nous voyons émerger (ou se démocratiser) de nombreuses pratiques spécifiques à ces méthodes de développement.

Parmi ces pratiques spécifiques il y en a une particulièrement importante dont le but est d’assurer une qualité des développements à travers une compréhension commune des fonctionnalités de l’ensemble des acteurs intervenant sur le logiciel. Je pense évidemment au BDD.

Le BDD a déjà fait l’objet de nombreux articles dans la taverne. Ces articles témoignent d’ailleurs d’une évolution de la vision (ou de la manière de la présenter) à travers les années.

La taverne publiait un article en 2018 (article plus ancien) pour écrire de bons BDD. Sur le fond l’article a raison et prône de bonnes pratiques dans l’écriture de test. Néanmoins on remarque qu’il existe une confusion entre les tests issus du BDD et le BDD lui même! Cette confusion n’existe plus car le BDD ce n’est pas les tests mais bien plus!

Le BDD c’est quoi exactement ?

Le BDD pourrait, de mon point de vue, presque être considéré comme une philosophie. Dans tous les cas, le BDD est une démarche qui pousse à la communication. On peut parler des 3 amigos, on peut parler d’automatisation des tests qui sont des pratiques courantes du BDD ou encore d’écriture de test en Gherkin, ces dernières ne le définissent pas.

On peut en effet faire du BDD sans automatiser les tests conçus, faire de meeting des 3 amigos, avoir une documentation vivante ou encore sans écrire en Gherkin! Il est possible d’appliquer ces pratiques sans faire de BDD!

Non, comme expliqué, le BDD est avant tout une démarche, qui fonctionne très bien avec les pratiques citées ci-dessus. Cette démarche simple consiste à communiquer afin de s’assurer que tous les acteurs (métier, testeurs, développeurs… en fait tous les intervenants sur le développement du logiciel) aient une compréhension commune de ce qui doit être fait avec la fonctionnalité.

Afin d’assurer cela il est possible de se réunir lors d’une réunion des 3 amigos mais cela peut évidemment prendre une autre forme. L’important reste la compréhension commune. Cette compréhension commune se traduite très souvent par des tests (mais cela pourrait également se traduire par des maquettes, schémas, vidéos ou tout autre chose) écrit dans un langage compréhensible par l’ensemble des acteurs… et même des personnes extérieures au produit (c’est pour cela que l’on utilise Gherkin).

La compréhension commune est la plupart du temps assurée à l’aide de tests conçus et partagés avant le début de tout développement de la fonctionnalité. Cette compréhension commune par différents profils permet d’ailleurs de relever des potentiels problèmes très tôt (un peu à l’image des revues).

La synchronisation est elle si importante ?

La raison pour laquelle on utilise généralement (quasiment tout le temps actuellement) des tests pour assurer une bonne compréhension c’est que ces derniers sont réutilisables mais aussi qu’illustrent assez simplement les fonctionnements attendus à l’aide d’exemples des comportements souhaités de la fonctionnalité.

Cette illustration par les exemples a pour but de permettre à toute personne d’éviter une mécompréhension ou tout simplement une compréhension différente des autres.

Cette différence de compréhension, qui est à la base de très nombreux échecs et conflits, est toujours présente et ce même sur un sujet trivial tel qu’une glace! Si quelqu’un demande une glace il est possible de servir un nombre très important de glaces différentes (boules, parfum, chantilly, stick…) ou même un miroir! Le BDD a justement pour but de permettre à l’ensemble de l’équipe de savoir quelle glace il faut livrer et de tous travailler dans le bon sens afin de livrer la bonne glace!

Conclusion

Le BDD est particulièrement important en Agile car il force l’ensemble des acteurs à se synchroniser et à adopter une vision commune. Même s’il est vrai que le BDD peut permettre de faciliter l’automatisation le plus important reste l’aspect humain qui est essentiel en Agile. L’important n’est pas le processus (3 amigos, écriture en gherkin) ou les outils utilisés mais bien les échanges entre les hommes et femmes qui travaillent sur le logiciel… on retombe alors sur une partie du manifeste Agile: « les individus et leurs interactions plus que les processus et les outils »

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

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

N’hésitez pas à faire vos propres retours d’expérience en commentaire.