En se basant sur le même principe de TDD (Test Driven Development), la pratique ATDD (Acceptance Test Driven Development) consiste à réunir et faire collaborer tous les acteurs d'un projet agile (développeurs, testeurs, parties prenantes, utilisateurs finaux) pour élaborer et écrire ensemble les tests d'acceptation d'une fonctionnalité ou User Story.
C'est toujours la même vision est objectif, qui est d'écrire les tests avant de coder une fonctionnalité ou une User Story, ces tests qui vont être la base et le guide pour les développeurs afin de créer techniquement cette fonctionnalité.
Avec la pratique ATDD, on met l'accent sur la collaboration avec le client et ses parties prenantes pour écriture ensemble les tests d’acceptation, tout en se basant sur un langage naturel compréhensible par les différents acteurs, et cela indépendamment du langage utilisé par les développeurs lors du codage.
Pour bien faire les choses, il est toujours souhaitable et recommandé d'utiliser des exemples réels et concrets qui reflètent la réalité lors de l'élaboration des tests d'acceptation, cela va aider toute l'équipe à éviter toute incompréhension du besoin, ainsi qu'éliminer les aller-retour lors de la phase de test.
l'écriture de ces tests d'acceptation peut être faite comme le cas pour les BDD (Behavior Driven Development), par un langage naturel en occurrence le "Gherkin" que je vais le détailler un peut dans un article à venir.
Ces pratiques de tests sont actuellement de mieux en mieux prises en charge par les outils de tests manuels qui existent sur le marché, ainsi que par les outils de conception et automatisation des tests.
Conclusion :
Que ça soit en phase de conception, de développement ou de test, on favorise toujours la collaboration et l’implication de tous les acteurs, pour avoir une même vision, la même compréhension, et pour éviter le gaspillage du temps tout au long du projet.
L'écriture des tests d'acceptation lors de la phase de raffinage des User Story permet aussi d'utiliser ces scénarios rédigés au fur et à mesure comme une documentation vivante du produit.
Comments