Pilotage par les tests d'acceptation

Après le TDD, voici l'ATDD.

Dans l'épisode précédent, nous avions vu qu'une story était un élément du backlog de produit.

Un principe, dans toutes les méthodes agiles, est qu'une story soit réalisée en une itération. Mais comment savoir si elle est vraiment finie à la fin de l'itération ?

C'est la responsabilité du product owner d'accepter ou pas une story. Pour cela, le moins qu'il puisse faire est de définir ses conditions de satisfaction. Si toutes les conditions sont satisfaites, la story est acceptée, sinon elle n'est pas considérée comme finie.

Chaque story possède donc un ou plusieurs tests. Un story test exprime une condition qui doit être satisfaite.

Ce qu'on appelle ATDD, c'est la technique qui consiste à ne commencer le développement d'une story (sa conception, son code, ses tests unitaires) que lorsqu'on dispose de ses tests d'acceptation.
L'ATDD implique, pour une story, les étapes suivantes :

  1. élaboration des story tests de la story
  2. développement de la story
  3. passage des story tests. En cas d'échec, correction des tests et/ou du code.

A noter

  • Si la story est réalisée dans l'itération n, cela implique que ces 3 étapes s'y déroulent, la première pouvant être anticipée dans l'itération n-1
  • Les 3 étapes ne sont pas nécessairement séquentielles, l'ajout de nouveaux tests peut se faire en parallèle avec le développement.

Pour vérifier la condition, il faut exécuter le test sur la dernière version du logiciel, le build courant. A chaque nouveau build, pour éviter les régressions, il conviendrait de repasser tous les story tests de toutes les stories. On comprend l'intérêt de l'automatisation.

Méta modèle test acceptation

Ce modèle est actuellement mis en place dans l'outil IceScrum. Cela va apporter aux utilisateurs d'IceScrum les facilités suivantes :

  • définir les tests associés aux stories, sous forme de conditions de satisfaction. Pour ceux qui le souhaitent, les tests peuvent être formalisés à partir du template BDD
  • enregistrer un nouveau build et remettre tous les tests dans l'état à passer
  • enregistrer le résultat de chaque exécution de test, succès ou échec
  • savoir quels tests ont été passés pour un build, le nombre de succès et d'échecs
  • connaître à tout moment l'état des tests d'acceptation d'une story

Commentaires

1. Le mercredi 04 février 2009, 15:42 par ManU

Désolé, je pinaille, mais je ne pense pas qu'il est juste de dire que l'ATDD est autre chose que du TDD.
En effet, le TDD contient plusieurs pratiques de tests:

  • les tests client/de recette/d'acceptance/boite-noire (choisissez votre vocabulaire préféré);
  • les tests développeurs/boite-blanche/unitaires (même remarque);
  • l'automatisation du rejeu des tests;
  • le test-first.

En fait, les tests d'acceptance sont déjà une pratique du TDD.
(à mon humble avis)

Tu as raison, mais le TDD est souvent réduit à du test unitaire.
Le terme ATDD est utilisé par Mike Cohn et Elisabeth Hendrickson, notamment. Dans les commentaires de ce billet, il y a d'ailleurs une discussion sur les acronymes. Tiens avec un membre du Cara il me semble.