Communiquer les tests d'acceptation aux développeurs

Quand et sous quelle forme le directeur de produit fournit les critères de tests d'une histoire d'utilisateur ?

Aujourd’hui j’ai défini des tests d’acceptation [1] pour des histoires d’utilisateur[2]. C’est mon boulot de directeur de produit[3] de préciser les critères qui permettront de s’assurer qu’une histoire est complète. C’est un exercice indispensable si on veut automatiser les tests d’acceptation. Si on n’automatise pas cela reste tout de même très important.

Par exemple pour l’histoire “En tant que participant à un projet, je démarre une tâche du plan”, des critères de test que j’ai identifiés sont :

  • on ne peut démarrer une tâche que si elle est dans l’état “prête”
  • seul celui à qui la tâche est affectée peut la démarrer
  • la date est enregistrée lorsque la tâche est démarrée

Comme on le voit, ces critères portent souvent sur des règles de gestion et sur des attributs du modèle métier.

2 points à noter sur ces tests d’acceptation :

  • Les histoires d’utilisateur sur lesquelles j’ai travaillé sont sélectionnées dans le sprint courant qui a déjà commencé. Cela veut dire que les développeurs ont déjà commencé à travailler sur certaines. C’est trop tard : pour une histoire, l’équipe avait fait des choix que j’ai remis en question. Il est préférable que les tests d’acceptation d’une histoire existent avant que le développement de cette histoire ne commence. Ce que je vais essayer pour les prochains sprints, c’est d’avoir préparé ces tests d’acceptation avant que le sprint ne commence [4]
  • Comme je ne suis pas toute la journée avec le reste de l’équipe, la communication passe par un support écrit[5]. Pas de document formel, l’objectif est seulement d’initier une conversation avec les développeurs ou les testeurs chargés d’automatiser les tests.

Notes

[1] ça s’appelait Customer tests dans la première version de XP. On disait aussi Functional Tests. Maintenant on emploie plutôt Acceptance tests. En France on parle dans un autre contexte de test de recette. Pour éviter les confusions, je préfère utiliser test d’acceptation

[2] user stories

[3] product owner

[4] c’est à dire que je définis les tests d’acceptation pendant le sprint n pour une histoire développée dans le sprint n+1

[5] sur un wiki

Voir aussi