Formaliser les critères d'acceptation

...ou comment rendre inutile la rédaction de spécifications détaillées.

Un des gaspillages les plus spectaculaires dans le développement de logiciel est l'écriture de spécifications détaillées suivie de la rédaction d'un cahier de recette, plus ou moins à partir de ces spécifications. Plutôt moins parce qu'en général le cahier de recette est écrit à la fin, à un moment où les specs, écrites au début, ne sont plus à jour depuis longtemps.

La technique des histoires d'utilisateur(user stories) permet d'obtenir des morceaux de fonctionnalité pouvant être finis en une itération. Fini signifiant au moins testé. A chaque histoire d'utilisateur sont associés des critères permettant au client de tester l'histoire. Ces critères d'acceptation peuvent être formalisés, pour aller un peu plus loin dans l'aide fournie à l'équipe que l'énoncé de ces critères. C'est d'ailleurs une des pratiques majeures de l'agilité que d'automatiser les tests et pour cela il faut bien formaliser.

Les différents tests associés à une histoire correspondent à des comportements différents du logiciel. Les comportements diffèrent parce que, en fonction de l'état du logiciel au moment où l'histoire est exécutée, les résultats obtenus seront différents. La technique du BDD permet de décrire ces comportements. Elle me rappelle des choses que j'ai utilisées il y a longtemps comme les automates à états et aussi la méthode orientée objet Fusion [1].

Chaque critère d'acceptation est formalisé avec 3 rubriques :

  • l'état du logiciel avant l'exécution de l'histoire (on parle aussi de précondition)
  • l'événement qui déclenche l'exécution
  • l'état du logiciel après l'exécution (on parle aussi de postcondition)

Exemple tiré du projet Wilos

Titre de l'histoire : Prendre une tâche

En tant que participant avec un rôle sur le projet, je prends une tâche à faire, afin de collaborer à la réussite du projet[2]

Critères de test associés

rôle concordant

Etant donné(l'état du logiciel avant) la tâche Analyser dans le projet P, tâche qui est libre, et le rôle Analyste joué par le participant Paulo sur P, Quand (l'événement) Paulo prend la tâche Analyser, Alors (le résultat : l'état après exécution) la tâche Analyser lui est associée

rôle incohérent

Etant donné la tâche Analyser dans le projet P, tâche qui est libre, et le rôle Concepteur joué par le participant Pierrot sur P, Quand Pierrot prend la tâche Analyser, Alors la tâche ne lui est pas associée et un message lui explique qu'il son rôle ne lui donne pas droit à cette tâche

tâche déjà prise

Etant donné la tâche Analyser dans le projet P, tâche qui est déjà prise, et le rôle Analyste joué par le participant Paulo sur P, Quand Paulo prend la tâche Analyser..., Alors la tâche Analyser ne lui est pas associée et un message lui explique qu'il ne peut pas prendre une tâche déjà prise.

L'histoire d'utilisateur composée de son titre, de son résumé et des critères d'acceptation associés décrits comme ci-dessus constitue un pont entre spécification et test. En plus de faciliter leur éventuelle automatisation, elle constitue la documentation de référence.

Notes

[1] je m'y intéressais en 1993 ! Fusion était une très bonne méthode qui a fondu dans UML malheureusement

[2] selon le plan type présenté dans ce billet