Intro
L’ATDD (Acceptance Test Driven Development) et le BDD (Behaviour Test Driven Development) sont des approches collaboratives, quasiment tout le temps implémenté dans des contextes de développement Agile, où l’on définit des tests collaborativement avant de commencer les développements. Ces similitudes font que bien souvent ces 2 méthodologies sont confondues / fusionnées alors qu’au final il y a, selon moi, une vraie différence de fond.
Définition
A noter: je vais présente ici les définitions proposées par l’ISTQB sur son site officiel.
BDD: Une approche collaborative du développement selon laquelle l’équipe se concentre sur la livraison du comportement attendu d’un composant ou d’un système pour le client, ce qui constitue la base des tests.
ATDD: Une approche collaborative du développement selon laquelle l’équipe et les clients utilisent le langage propre au domaine du client pour comprendre ses exigences, ce qui constitue la base pour tester un composant ou un système.
Les 2 définitions parlent d’approches collaboratives. Néanmoins pour l’ATDD on remarque la présence du client alors que ce n’est pas le cas pour le BDD où seule l’équipe (cela inclut quand même un représentant client, le PO en Scrum) est mentionnée. De même on peut également noter que l’objectif est différent. Pour le BDD on parle de comportement d’un système (spécifications) alors que pour l’ATDD on parle de comprendre les exigences du client pour pouvoir tester.
Pourquoi cette confusion ?
Il y a pour moi de nombreuses raisons qui entrainent cette confusion, ou plutôt cette « fusion » des approches. Les principales sont:
- La présence de 2 visions de l’ATDD qui « s’opposent« . Celle des « développeurs » où l’ATDD c’est l’automatisation de scénarios d’acceptation conçus pour les User Story et celle des « testeurs » (mon point de vue) où l’ATDD doit proposer des tests d’acceptation. J’en parlais d’ailleurs dans mon article sur l’automatisation des tests d’acceptation.
- La frontière proposée par les certifications (fondation et testeur technique Agile) ISTQB est moins claire que celle du glossaire. Cette Différence se fait essentiellement sur l’expression du test, sa manière de l’écrire, le BDD étant souvent reconnu avec l’usage du gherkin.
- La séparation tests système et tests d’acceptation reste floue pour beaucoup de personnes. Cette confusion sur les niveaux de test est pour moi la vraie différence entre le BDD et l’ATDD.
Conclusion
Les approches ATDD et BDD, tout comme les tests systèmes et tests d’acceptation, peuvent se ressembler sur la forme et leur méthodologie mais elles ont des objectifs différents. Ces objectifs, proches des niveaux de test, peuvent paraître assez flous pour une grande partie des acteurs du numérique.
De plus 2 visions de l’ATDD s’opposent actuellement. Une de ces visions voit l’ATDD comme étroitement liée aux scénarios d’acceptation des User Story.
Enfin, ces approches, même si elles divergent sur leur finalité partent d’une problématique commune: les divergences de compréhension entre les différents acteurs. Dans tous les cas, ATDD ou BDD, je ne peux que vous conseiller de mettre en pratique ces approches dans votre quotidien.
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.
