Critères d’acceptation

En anglais : Acceptance criteria

Également appelé : critère d’acceptation, conditions d’acceptation

Définition

Les conditions précises et testables qu’une user story ou une fonctionnalité doit remplir pour être acceptée comme terminée par le product owner.

Les critères d’acceptation sont les conditions qui définissent quand une user story est terminée du point de vue métier. Chaque critère est une affirmation claire et testable, dont le résultat est soit réussi, soit échoué. Ils sont convenus pendant l’affinage (refinement), avant le début du développement, et deviennent le point de départ des scénarios de test et des vérifications automatisées.

Exemple

Story : en tant qu’acheteur, je veux appliquer un code de réduction au moment de payer afin de bénéficier du prix promotionnel.

Format à base de règles :

Un code valide et non expiré réduit le total de la commande du pourcentage associé au code.
Un code expiré affiche « This code has expired » et ne modifie pas le total.
Un seul code peut être appliqué par commande ; en appliquer un second remplace le premier.
Les codes ne sont pas sensibles à la casse (SAVE10 et save10 sont équivalents).

Le même critère sur le code expiré, au format Given/When/Then (Étant donné/Quand/Alors) :

Scenario: Expired discount code is rejected
  Given my cart total is $50.00
  And the code "SPRING10" expired yesterday
  When I apply the code "SPRING10"
  Then I see the message "This code has expired"
  And my cart total is still $50.00

Critères d’acceptation et Definition of Done

Les critères d’acceptation sont propres à une story : ce que cette fonctionnalité doit faire. La Definition of Done (définition de « terminé ») s’applique à toutes les stories : code relu, tests automatisés, documentation mise à jour, déploiement en préproduction. Une story n’est terminée que lorsqu’elle satisfait les deux.

Rédiger de bons critères

Testables. « La page se charge rapidement » n’est pas testable ; « la page de résultats s’affiche en moins de 2 secondes pour 1 000 produits sur le jeu de données de préproduction » l’est.
Le comportement, pas l’implémentation. Décrivez des résultats, pas la table de base de données qui change.
Inclure les cas négatifs. Les saisies invalides, les permissions et les messages d’erreur font partie de la fonctionnalité.
Validés par les « three amigos ». Produit, développement et test les relisent ensemble. C’est là que les testeurs apportent le plus de valeur, en demandant « que se passe-t-il si… ? » avant que le code ne soit écrit.