Critères d'acceptation

Les critères d'acceptation définissent les conditions qui doivent être remplies pour qu'une user story soit considérée comme terminée. Ils transforment des exigences vagues en spécifications testables, éliminant l'ambiguïté et empêchant la dérive du périmètre.

Objectif

Les critères d'acceptation servent plusieurs rôles :

Pour les développeurs : Exigences claires avant de commencer à coder Pour les testeurs : Conditions exactes à vérifier Pour les parties prenantes : Définition transparente des livrables Pour les product owners : Application des limites du périmètre

Sans critères d'acceptation, "terminé" devient subjectif. Avec eux, la complétion est binaire—tous les critères passent ou le travail continue.

Accéder à l'éditeur

Ouvrez les critères d'acceptation depuis les détails de la user story :

1. Naviguez vers n'importe quelle user story
2. Cliquez sur l'onglet Détails
3. Trouvez la section Critères d'acceptation
4. Cliquez sur le bouton Modifier (icône crayon)

L'éditeur s'ouvre dans une fenêtre modale avec des options de formatage de texte enrichi.

Fonctionnalités de l'éditeur

Barre d'outils de formatage

L'éditeur de critères d'acceptation supporte :

Support du texte enrichi

L'éditeur préserve le formatage lors du collage depuis :

• Google Docs
• Confluence
• Notion
• Microsoft Word

Collez le contenu formaté directement—la structure se transfère automatiquement.

Rédiger des critères efficaces

Le format Given-When-Then

Cette structure crée des conditions non ambiguës et testables :

Étant donné [précondition]
Quand [action]
Alors [résultat attendu]

Exemple :

Étant donné que je suis connecté en tant qu'administrateur
Quand je clique sur "Supprimer l'utilisateur" et confirme le dialogue
Alors l'utilisateur est supprimé du système
Et je vois une notification de succès
Et l'utilisateur n'apparaît plus dans la liste des utilisateurs

Format checklist

Pour des validations plus simples, utilisez des cases à cocher :

- [ ] Le formulaire valide le format email
- [ ] Le mot de passe requiert 8+ caractères
- [ ] Le bouton soumettre est désactivé jusqu'à ce que le formulaire soit valide
- [ ] Les messages d'erreur s'affichent sous les champs invalides
- [ ] Le succès redirige vers le tableau de bord

Spécification par l'exemple

Montrez le comportement attendu exact :

Entrée : "jean@exemple.com"
Attendu : Valide, passer à l'étape suivante

Entrée : "jean@"
Attendu : Erreur "Format email invalide"

Entrée : ""
Attendu : Erreur "L'email est requis"

Catégories de critères

Critères fonctionnels

Ce que la fonctionnalité doit faire :

Étant donné un utilisateur avec des articles dans le panier
Quand il clique sur "Commander"
Alors il voit le formulaire de paiement
Et le total du panier s'affiche correctement
Et les options de livraison sont calculées

Critères non-fonctionnels

Comment la fonctionnalité doit performer :

Performance :
- La page charge en moins de 2 secondes
- La recherche retourne les résultats en moins de 500ms
- Supporte 100 utilisateurs simultanés

Accessibilité :
- Tous les champs de formulaire ont des labels
- La navigation par tabulation fonctionne correctement
- Compatible avec les lecteurs d'écran

Cas limites

Conditions aux limites et états d'erreur :

Cas limites gérés :
- Une recherche vide retourne un message utile
- Un timeout réseau affiche l'option de réessayer
- L'expiration de session redirige vers la connexion
- Les données invalides affichent des erreurs spécifiques

Critères de sécurité

Exigences de protection :

Exigences de sécurité :
- Les mots de passe sont hashés avant stockage
- La session expire après 30 min d'inactivité
- Les tentatives de connexion échouées limitées à 5
- Les données sensibles ne sont pas loguées

Anti-patterns à éviter

Trop vague

❌ Mauvais :

- Devrait fonctionner correctement
- Doit être rapide
- Doit gérer les erreurs

✅ Bon :

- Retourne un statut 200 sur entrée valide
- Répond en moins de 500ms en charge normale
- Affiche "Erreur réseau, veuillez réessayer" sur timeout

Trop technique

❌ Mauvais (sauf si l'équipe est entièrement développeurs) :

- Utilise Redis pub/sub pour les mises à jour temps réel
- Implémente le verrouillage optimiste avec ETag
- Déploie via Kubernetes rolling update

✅ Bon :

- Les changements apparaissent pour tous les utilisateurs en 3 secondes
- Les modifications simultanées affichent un avertissement de conflit
- Le déploiement ne cause aucune interruption de service

Tester l'implémentation

❌ Mauvais :

- Utilise correctement les hooks React
- Les requêtes base de données sont optimisées
- Le code suit le guide de style

✅ Bon :

- Le composant ne se re-rend que quand les données changent
- La liste charge en moins de 1 seconde pour 10 000 éléments
- Cohérent avec les patterns UI existants

Dérive du périmètre

❌ Mauvais (ajoute du travail hors story) :

- Ajouter aussi le support du mode sombre
- Inclure l'export en PDF
- Ajouter les raccourcis clavier

✅ Bon (rester dans le périmètre de la story) :

- Le tableau de bord affiche tous les widgets
- Les widgets chargent la configuration sauvegardée de l'utilisateur
- La mise en page persiste entre les sessions

Intégration au workflow

Pendant la planification

1. Création de story : Rédiger les critères initiaux
2. Affinage : L'équipe discute, ajoute les cas limites
3. Estimation : Les critères informent l'attribution des story points
4. Planification de sprint : Les critères vérifient que la story est prête

Pendant le développement

1. Référence : Le développeur vérifie les critères en codant
2. Auto-test : Le développeur vérifie chaque critère avant la PR
3. Revue de code : Le reviewer vérifie la couverture des critères

Pendant les tests

1. Création de cas de test : Chaque critère devient un cas de test
2. Vérification : Le testeur valide tous les critères
3. Rapports de bug : Référence les critères spécifiques qui échouent

Pendant la démo

1. Démonstration : Montrer chaque critère satisfait
2. Validation : La partie prenante confirme l'acceptation

Raccourcis clavier

Dans l'éditeur de critères d'acceptation :

Bonnes pratiques

1. Rédiger les critères avant le développement

Les critères rédigés après le code ont tendance à correspondre à l'implémentation plutôt qu'aux exigences. Rédigez d'abord, codez ensuite.

2. Impliquer l'équipe

Les développeurs repèrent les lacunes techniques. Les testeurs trouvent les cas limites. Incluez les deux perspectives lors de la rédaction.

3. Garder les critères atomiques

Chaque critère teste une seule chose :

❌ Combiné :

L'utilisateur peut se connecter avec les bons identifiants et voit le tableau de bord avec ses données

✅ Atomique :

- Les identifiants valides accordent l'accès
- Les identifiants invalides affichent une erreur
- Le tableau de bord s'affiche après la connexion
- Le tableau de bord montre uniquement les données de l'utilisateur

4. Utiliser un langage cohérent

Établissez des conventions d'équipe :

• "Utilisateur" vs "Client" vs "Membre"
• "Cliquer" vs "Sélectionner" vs "Choisir"
• "Afficher" vs "Montrer" vs "Rendre"

5. Inclure les cas négatifs

Ce qui ne doit PAS arriver compte aussi :

- Le mot de passe n'est jamais affiché dans les logs
- Les données supprimées ne peuvent pas être récupérées
- Une session expirée ne peut pas accéder aux routes protégées

6. Versionner les critères

Quand les exigences changent, mettez à jour les critères et notez pourquoi :

Mis à jour 2024-01-15 : Ajout exigence 2FA suite à l'audit sécurité
Précédent : La connexion requiert email + mot de passe
Actuel : La connexion requiert email + mot de passe + code 2FA

Templates courants

Opérations CRUD

Créer :
- Une entrée valide crée l'enregistrement
- Une entrée invalide affiche des erreurs spécifiques
- La prévention des doublons fonctionne

Lire :
- Les utilisateurs autorisés voient les données
- Les utilisateurs non autorisés voient une erreur
- L'état vide affiche un message utile

Mettre à jour :
- Les modifications se sauvegardent correctement
- La validation s'applique aux mises à jour
- La gestion des modifications simultanées fonctionne

Supprimer :
- Confirmation requise
- La suppression douce préserve les données
- La suppression définitive supprime complètement

Validation de formulaire

Champ : Email
- Requis (affiche erreur si vide)
- Validation du format (utilisateur@domaine.com)
- Longueur max : 254 caractères
- Vérification unicité (affiche erreur si existe)

Champ : Mot de passe
- Requis
- Minimum 8 caractères
- Au moins un chiffre
- Au moins un caractère spécial
- L'indicateur de force s'affiche

Endpoint API

Endpoint : GET /api/users/{id}

Succès (200) :
- Retourne l'objet utilisateur
- Exclut les champs sensibles (mot de passe, tokens)
- Temps de réponse < 200ms

Non trouvé (404) :
- Retourne le format d'erreur standard
- Message : "Utilisateur non trouvé"

Non autorisé (401) :
- Token manquant retourne erreur
- Token expiré retourne erreur
- Token invalide retourne erreur

Dépannage

Le formatage ne se sauvegarde pas :

• Vérifiez la console du navigateur pour les erreurs
• Essayez de vider le cache du navigateur
• Assurez-vous d'avoir une connexion réseau stable

L'éditeur ne s'ouvre pas :

• Vérifiez la permission edituserstories
• Vérifiez que la story n'est pas archivée
• Rafraîchissez la page et réessayez

Le contenu collé perd son format :

• Essayez Coller et adapter le style (Cmd/Ctrl + Shift + V)
• Utilisez le format Markdown pour le contenu complexe
• Divisez en opérations de collage plus petites

Les modifications ne sont pas visibles par l'équipe :

• Vérifiez que la sauvegarde est terminée (modal fermée)
• Vérifiez les erreurs de synchronisation dans le flux d'activité
• Les membres de l'équipe peuvent avoir besoin de rafraîchir