Introduction :
Les BDD sont de plus en plus mis en avant. D’après le sondage sur le futur du test les xDD font d’ailleurs partie intégrante du futur des tests (xDD : 13%, rapprochement BDD et MBT : 22%) pour beaucoup de personnes.
Pourquoi est-ce le cas ? Pourquoi les BDD (et l’ATDD) pourraient être future grande évolution du test ? Pourquoi les BDD ont-ils autant de succès ? Nous allons dans cet article nous attarder sur ces questions afin d’y répondre.
D’autres articles sur le BDD sont présents dans la taverne. Je vous recommande notamment l’article de Bruno Legeard qui voit le BDD comme une documentation vivante ou l’article de Laurent Bouhier qui propose de bonnes pratiques pour écrire ses BDD.
Qu’est-ce que le BDD ?
Le BDD (Behaviour Driven Development) part d’un principe simple qui est que la communication entre les spécialistes des exigences, les développeurs et les testeurs n’est pas optimale car ils n’ont pas de vocabulaire commun.
Le BDD propose ce vocabulaire commun en illustrant par des exemples le comportement souhaité de l’application. Le vocabulaire commun est le fait de présenter une fonctionnalité suivant 3 points :
- Given (était initial) qui décrit l’était initial de l’application avant ses actions et l’utilisation de la fonctionnalité
- When (lorsque) qui décrit des actions et un évènement
- Then (alors) qui décrit le résultat des actions/évènements
Il existe « And » (et) qui peut être ajouté n’importe où.
Ces mots permettent de décrire des scénarios d’utilisation (When puis Then ressemble fortement à des tests), on peut par exemple avoir pour une notification :
Given : Mon application mail tourne en arrière-plan sur mon smartphone
And : j’ai une connexion internet fonctionnelle sur mon téléphone
When : Je reçois un nouveau mail dans ma boite de réception
Then : j’ai une notification qui s’affiche sur mon téléphone
Grâce à ce langage que tout le monde comprend il est plus aisé de communiquer. De même, ce langage pouvant être très précis (en utilisant des exemples et étant assez bas niveau) il est également possible d’automatiser ses tests à partir de ces BDD, des outils comme HipTest, Yest, KaliosTest, Gherkin et RobotFramework proposent d’ailleurs cette fonctionnalité.
Un petit retour sur le cycle de développement :
Le cycle de développement et plus généralement cycle de vie d’un logiciel est encore très séquentiel :
Expression de besoin => Spécifications => Développement => Test => exploitation
L’agilité tend à limiter ce séquençage et de manière générale la philosophie DevOps veut casser ces silos. Une des raisons du succès de DevOps et de l’agilité est justement le fait d’atténuer ces frontières virtuelles et de favoriser la communication.
En effet, avec un séquençage strict il y a toujours une perte de connaissance entre 2 étapes mais aussi une montée en compétence nécessaire à chaque début de séquence. Toutes ces transitions se révèlent très coûteuse c’est pourquoi c’est une bonne chose d’encourager une bonne communication entre les différents acteurs et que l’on parle régulièrement de shift left mais aussi de plus en plus de shift right.
L’apport du BDD :
Le BDD, par sa structure permet de simplifier la communication entre les équipes/membres du projet et par conséquence de limiter le coût des phases de transitions.
Néanmoins ce n’est pas tout. Comme il est dit dans l’article de Bruno Legard, le BDD devient une documentation vivante des projets agiles. Par cela on peut entendre que, les user storys écrites en BDD se transforment en test, que ces tests sont mis à jour et qu’avec eux c’est toute une documentation qui est mise à jour. On voit ici que des tests mis à jours permettent d’avoir des « spécifications » également mise à jour.
Je vais encore plus loin, de mon point de vue, si les BDD sont correctement mis en place ils ne permettent pas seulement de limiter la maintenance et d’être une documentation vivante ! En effet si les BDD sont bien mis en place il peuvent permettre de fusionner les étapes de test (faites à partir des spécifications) et les étapes de spécifications… Cela revient à aller encore plus loin que le DevOps car ici on ne supprime par une barrière, on ne détruit pas un silo en transforme 2 tâches en 1 seule !
Cette fusion est justement, de mon point de vue, la grande force du BDD et la principale raison pour laquelle le BDD peut devenir une part importante du futur du test. En effet, cette fusion possible permet de :
- Gagner du temps sur les projets en ne faisant qu’une tâche au lieu de 2 qui prennent chacune autant de temps que la tâche qui se retrouve seule
- Une meilleure communication
- Une diminution du nombre d’intervenants
- Avoir une documentation, des spécifications et des tests à jour en ne faisant qu’une seule mise à jour
- Automatiser facilement des tests
- Rendre l’automatisation plus aisée car BDD rime avec KDT
Conclusion :
Bref, comme vous l’aurez compris, le BDD va, selon moi, continuer à se développer, à prendre de l’importance. La raison principale de cette évolution sera une simplification du travail par une diminution des tâches à effectuer en plus d’offrir une meilleure communication au sein de l’équipe.
Enfin, dans le titre je parle d’ATDD/BDD mais n’aborde que le BDD. La raison est simple, pour le moment (d’après mon expérience et mes discussions), l’ATDD et le BDD ne sont pas vraiment différents. Néanmoins, sur le papier, l’ATDD (Acceptance Test Driven Development) est plus haut niveau. Là où le BDD correspond aux tests système, l’ATDD devrait correspondre aux tests d’acceptation. Ce n’est pas encore le cas mais cela le deviendra sûrement. Lorsque cela sera le cas, une barrière pourrait être détruite, la barrière entre l’expression de besoin et les spécifications. Dans ce cas les BDD pourraient être issus des ATDD mais en étant plus précis.
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
Une réponse