Pilotage par les tests d'acceptation

Méta-modèle

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.

À 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.

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

Voir aussi