Critères d'Acceptation

Deux formats sont dominants dans les équipes produit SaaS. Le format Given-When-Then (syntaxe Gherkin) est très structuré et correspond directement aux cas de test automatisés : "ÉTANT DONNÉ un utilisateur connecté sur le tableau de bord, QUAND il clique sur 'Exporter', ALORS un fichier CSV est téléchargé en moins de 5 secondes contenant toutes les colonnes de la vue filtrée actuelle." Ce format est préféré pour les interactions utilisateur complexes. Le format Liste de contrôle (Checklist) est plus simple et plus rapide : une liste à puces de conditions (par exemple, "Le bouton apparaît uniquement pour les utilisateurs Admin", "Les exportations respectent le filtre de date actif", "Une notification toast apparaît à la fin"). Les listes de contrôle sont meilleures pour les stories plus petites. Le Product Ops établit la norme pour le format à utiliser et fournit des modèles dans l'outil de gestion de projet de l'équipe.

Les critères d'acceptation de haute qualité partagent cinq propriétés : Spécifiques — ils décrivent un comportement exact, pas un objectif vague ("Charge en moins de 2 secondes" vs. "Charge rapidement"). Testables — tout ingénieur ou ingénieur QA peut les vérifier indépendamment sans interprétation. Complets — ils couvrent le chemin nominal, les états d'erreur, les cas limites et les considérations de contrôle d'accès. Convenus — ils sont examinés et approuvés par l'Ingénierie avant qu'une story n'entre dans le sprint (non écrits unilatéralement par le PM). Concis — ils sont aussi courts que possible tout en restant non ambigus ; des critères d'acceptation longs indiquent souvent que la story est trop grande et devrait être divisée. Le Product Ops audite les stories pour la complétude des critères d'acceptation dans le cadre de la vérification du backlog "prêt pour le sprint" avant chaque cérémonie de planification.

Les critères d'acceptation servent de source de vérité pour l'assurance qualité. Chaque critère doit correspondre à au moins un cas de test dans la suite QA — qu'il soit automatisé (unitaire, d'intégration ou de bout en bout) ou manuel (documenté dans le plan de test). Lorsque les critères d'acceptation sont rédigés au format Gherkin, ils peuvent être directement implémentés comme tests automatisés à l'aide de frameworks comme Cucumber ou Cypress. Cette pratique — le Behavior-Driven Development (BDD) — garantit que les critères d'acceptation rédigés pendant la planification pilotent réellement la vérification automatisée, bouclant la boucle entre la spécification et les tests. Le Product Ops travaille avec l'Ingénierie et la QA pour établir la pratique BDD et s'assure que chaque story atteignant le statut "done" a un cas de test attaché pour chaque critère d'acceptation.