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[1] à partir de ces spécifications.

La technique des histoires d'utilisateur[2] permet d'obtenir des morceaux de fonctionnalité pouvant être finis en une itération. Fini signifiant complètement testé. A chaque histoire d'utilisateur sont associés des critères permettant au client d'accepter l'histoire, c'est à dire de considérer qu'elle est vraiment finie. 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. En m'inspirant de la méthode orientée objet Fusion sur laquelle j'ai beaucoup travaillé[3] , je propose de décrire chaque critère d'acceptation avec un exemple basé sur :

  • 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 pour une histoire d'utilisateur 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[4]

Critères de test associés

1- rôle concordant

Etant donné[5] 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 [6]Paulo prend la tâche Analyser

Alors [7]la tâche Analyser lui est associée

2 - 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

3 - 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[8] qui rend inutile tout autre documentation.

Notes

[1] plutôt moins parce qu'en général le cahier de recette est écrit à la fin et les specs, écrites au début, ne sont plus à jour

[2] user stories

[3] en 1993 ! Fusion était une très bonne méthode qui a fondu dans UML malheureusement

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

[5] l'état du logiciel avant

[6] l'événement

[7] le résultat après exécution

[8] en plus de faciliter leur éventuelle automatisation