Dans l’environnement rapide du développement logiciel, l’écart entre ce qu’un acteur principal imagine et ce qu’un développeur construit peut être considérable. Cet écart est souvent comblé par les Critères d’acceptation de l’histoire utilisateur. Pour les équipes de garantie de qualité (QA), ces critères ne sont pas seulement une liste de contrôle ; ils constituent le contrat de qualité. Lorsqu’ils sont rédigés clairement, ils transforment l’ambiguïté en scénarios de test exploitables.
De nombreuses équipes peinent avec des exigences floues. Des expressions comme « convivial » ou « chargement rapide » apparaissent fréquemment dans les premiers brouillons, mais échouent sous l’examen rigoureux des tests. Ce guide propose une approche structurée pour rédiger critères d’acceptation vérifiables qui permettent aux ingénieurs QA de mieux s’exprimer, réduisent les fuites de défauts et assurent une cohérence entre les fonctions Produit, Développement et Tests.
🎯 Pourquoi les critères d’acceptation vérifiables sont-ils importants
Les critères d’acceptation (AC) définissent les limites d’une histoire utilisateur. Ils précisent les conditions qui doivent être remplies pour que l’histoire soit considérée comme terminée. Pour les professionnels de la QA, ces énoncés constituent la base de la création des cas de test. Sans eux, les tests deviennent une simple supposition.
- Clarté des attentes : Des critères clairs éliminent les erreurs d’interprétation entre les rôles.
- Tests efficaces : Des conditions précises permettent aux testeurs d’écrire immédiatement des cas de test précis.
- Réduction des reprises : L’ambiguïté conduit souvent à construire la mauvaise fonctionnalité. De bons AC préviennent ce gaspillage.
- Soutien aux tests automatisés : Les énoncés vérifiables sont des prérequis pour les scripts d’automatisation.
Lorsque les AC sont flous, l’équipe QA doit consacrer du temps à clarifier les exigences pendant la sprint, ralentissant ainsi la livraison. Lorsqu’ils sont précis, l’attention se concentre entièrement sur la validation et la garantie de qualité.
🔍 Caractéristiques d’un énoncé vérifiable
Toute exigence n’est pas vérifiable. Un énoncé n’est valable que s’il peut être vérifié de manière objective. Pour garantir la vérifiabilité, les critères doivent respecter les principes suivants :
- Sans ambiguïté : Il n’existe qu’une seule interprétation de l’énoncé.
- Vérifiable : Il est possible de confirmer le succès ou l’échec par observation ou données.
- Atomique : Chaque critère traite d’une seule condition, et non d’une exigence combinée.
- Relevante : Elle est directement liée à l’objectif de l’histoire utilisateur.
- Conforme : Elle ne contredit pas d’autres critères ou contraintes du système.
Pensez à la différence entre un langage subjectif et un langage objectif. Les termes subjectifs reposent sur l’opinion, tandis que les termes objectifs reposent sur des données.
📉 Exemples de langage subjectif vs. objectif
| Subjectif (à éviter) | Objectif (cible) |
|---|---|
| La page doit se charger rapidement. | La page doit se charger en moins de 2 secondes sur une connexion 3G. |
| Le système doit être sécurisé. | Les mots de passe doivent être chiffrés à l’aide du hachage SHA-256. |
| Les utilisateurs doivent trouver facile de naviguer. | Les utilisateurs peuvent atteindre la page de paiement en moins de 3 clics depuis la page d’accueil. |
| Le rapport doit avoir une bonne présentation. | Le rapport doit afficher un total de 5 colonnes avec des en-têtes alignés. |
Remarquez comment les versions objectives fournissent des métriques, des méthodes ou des chiffres précis. Cela permet à un testeur d’effectuer une décision de réussite/échec sans consulter le propriétaire du produit.
🛠 Techniques d’écriture pour les critères d’acceptation
Plusieurs formats existent pour documenter les critères d’acceptation. Le choix dépend du niveau de maturité de l’équipe et de la complexité de la fonctionnalité. Voici les méthodes les plus efficaces.
1. Énoncés en langage courant
Des phrases simples et déclaratives fonctionnent bien pour les fonctionnalités simples. Cette approche est accessible aux parties prenantes non techniques.
- Lorsque l’utilisateur clique sur le bouton Envoyer, un message de succès s’affiche.
- Lorsque l’utilisateur saisit une adresse e-mail invalide, un message d’erreur s’affiche sous le champ.
- Le système ne doit pas autoriser la création de comptes en double avec la même adresse e-mail.
2. Syntaxe Gherkin (Étant donné/Quand/Alors)
Ce format s’aligne étroitement avec le développement piloté par le comportement (BDD). Il structure les critères en contexte, action et résultat. Il est fortement préféré pour les flux complexes.
- Étant donné : L’utilisateur est sur la page de connexion.
- Quand : L’utilisateur saisit un nom d’utilisateur et un mot de passe valides.
- Alors : Le système redirige l’utilisateur vers le tableau de bord.
Cette structure oblige l’auteur à considérer explicitement les préconditions et les résultats attendus.
3. Format de liste de contrôle
Parfois, une liste de conditions est suffisante, notamment pour les mises à jour de l’interface utilisateur ou les changements de configuration. Chaque élément représente une condition vérifiable.
- L’en-tête affiche le logo de l’entreprise.
- La barre de navigation reste fixe en haut pendant le défilement.
- Le pied de page contient l’année du droit d’auteur et des liens légaux.
- Le formulaire de contact exige le prénom et le nom de famille.
🤝 Stratégies de collaboration
Rédiger les critères d’acceptation est rarement une tâche individuelle. Elle nécessite des contributions du Product Owner, des développeurs et des ingénieurs QA. La réunion des « Trois Amis » est une pratique courante où ces trois rôles se réunissent pour définir ensemble les critères.
Objectifs clés de collaboration
- Compréhension partagée : Assurez-vous que tout le monde interprète les exigences de la même manière.
- Vérification de faisabilité : Les développeurs confirment si les critères sont techniquement réalisables.
- Revue de testabilité : Le QA s’assure que les critères peuvent être vérifiés sans ambiguïté.
- Identification des cas limites : Le groupe discute de ce qui se passe lorsque les choses tournent mal.
En impliquant le QA dès la phase de rédaction, les éventuels blocages sont identifiés avant le début du développement. Cela réduit le risque de découvrir des défauts critiques en fin de cycle.
⚠️ Pièges courants et anti-modèles
Même les équipes expérimentées tombent dans des pièges lors de la rédaction des critères. Reconnaître ces modèles aide à maintenir une qualité élevée.
1. Inclure des détails d’implémentation technique
Les critères d’acceptation doivent décrirece que le système fait, et non pascomment il le fait. Les détails d’implémentation appartiennent aux documents de conception technique.
- Mauvais : La base de données doit utiliser une table MySQL nommée utilisateurs.
- Bon : Le système doit stocker les identifiants des utilisateurs de manière sécurisée et les récupérer pour l’authentification.
2. Surcharge de plusieurs fonctionnalités
Chaque critère doit traiter un comportement spécifique. Combiner plusieurs comportements crée une condition complexe difficile à tester.
- Mauvais : L’utilisateur peut se connecter et voir sa photo de profil.
- Bon : L’utilisateur peut se connecter. Le profil utilisateur affiche l’image téléchargée.
3. Utiliser excessivement des formulations négatives
Bien que le test négatif soit important, trop d’énoncés du type « ne doit pas » peuvent masquer le flux principal.
- Mauvais : Le système ne doit pas autoriser les valeurs nulles. Le système ne doit pas autoriser les chaînes vides. Le système ne doit pas autoriser les caractères spéciaux.
- Bon : Le système valide les champs de saisie pour s’assurer qu’ils contiennent uniquement des caractères alphanumériques et ne sont pas vides.
4. Ignorer les exigences non fonctionnelles
Les critères fonctionnels sont essentiels, mais la performance, la sécurité et l’accessibilité comptent aussi. Ils doivent être inclus s’ils ont un impact sur l’expérience utilisateur.
- Le temps de réponse ne doit pas dépasser 200 ms pour les requêtes de recherche.
- L’interface doit prendre en charge la navigation au clavier pour tous les éléments interactifs.
- La transmission des données doit être chiffrée via HTTPS.
🧩 Cas limites et conditions aux limites
Les parcours standard sont faciles à écrire. La véritable valeur du test qualité réside dans l’exploration des limites. Les critères d’acceptation doivent mentionner explicitement la manière dont le système gère les entrées extrêmes ou inhabituelles.
Catégories de cas limites
- Valeurs nulles : Que se passe-t-il si une quantité est égale à 0 ?
- Limites maximales : Quel est le nombre maximum de caractères pour un champ de texte ?
- États nuls : Comment l’interface utilisateur s’affiche-t-elle lorsque les données manquent ?
- Actions concurrentes : Que se passe-t-il si deux utilisateurs modifient le même enregistrement simultanément ?
- Pannes de réseau : Comment le système se comporte-t-il lorsque la connexion internet est interrompue ?
Exemple de critère de cas limite :
- Si un utilisateur tente de télécharger un fichier supérieur à 50 Mo, le système affiche un message d’erreur et rejette le fichier.
🔄 Maintenance et évolution
Les critères d’acceptation ne sont pas des documents statiques. Au fur et à mesure que le produit évolue, les critères doivent évoluer également. Le restructurage du code nécessite souvent la mise à jour des critères pour correspondre aux nouveaux comportements.
Meilleures pratiques de maintenance
- Revue pendant la planification du sprint :Revoyez les anciennes histoires pour vous assurer que les critères correspondent toujours au comportement actuel.
- Mise à jour après correction d’un bogue :Si un bogue révèle une condition manquante, ajoutez-la aux critères d’acceptation immédiatement.
- Archiver les critères obsolètes :Supprimez les critères qui ne s’appliquent plus afin d’éviter toute confusion.
- Contrôle de version :Gardez un historique des modifications apportées aux critères aux fins d’audit.
Maintenir les critères à jour garantit que les tests de régression restent efficaces. Des critères obsolètes entraînent des faux positifs, où les tests passent même si la fonctionnalité a changé.
📊 Mesure de la qualité des critères d’acceptation
Comment savoir si vos critères d’acceptation fonctionnent ? Utilisez des indicateurs pour évaluer leur efficacité au fil du temps.
- Couverture des cas de test :Une haute couverture indique des critères clairs. Une faible couverture suggère une ambiguïté.
- Fuite de défauts :Si des bogues parviennent en production et contredisent les critères d’acceptation, ceux-ci étaient probablement insuffisants.
- Temps de clarification :Suivez le temps que le QA passe à poser des questions sur les exigences. Un temps élevé indique des critères d’acceptation de mauvaise qualité.
- Taux d’automatisation :Un taux élevé d’automatisation est corrélé à des critères testables et sans ambiguïté.
Les rétrospectives régulières peuvent aider les équipes à discuter de ces indicateurs et à ajuster leur processus d’écriture en conséquence.
🔗 Intégration avec la Définition de Fin
Les critères d’acceptation sont spécifiques à une histoire utilisateur. La Définition de Fin (DoD) s’applique à l’ensemble du déploiement ou du sprint. Ils travaillent ensemble mais ont des objectifs différents.
- DoD : « Toute le code revue », « Tous les tests unitaires passés », « Documentation mise à jour. » (Normes globales)
- AC : « L’utilisateur peut réinitialiser son mot de passe par e-mail. » (spécifique à la fonctionnalité)
Une histoire n’est complète que lorsque les deux critères d’acceptation sont remplis et que le critère de fin est satisfait. Les équipes de QA doivent vérifier les deux couches pour valider une fonctionnalité.
💡 Exemples pratiques
Pour consolider la compréhension, examinons un exemple complet d’une histoire utilisateur avec des critères faibles et améliorés.
Histoire : Fonctionnalité de réinitialisation du mot de passe
❌ Critères d’acceptation médiocres
- L’utilisateur peut réinitialiser son mot de passe.
- Le système envoie un courriel.
- Le lien expire après un certain temps.
- La sécurité est importante.
✅ Critères d’acceptation améliorés
- Étant donné que l’utilisateur est sur la page de connexion, lorsqu’il clique sur « Mot de passe oublié », il est redirigé vers le formulaire de réinitialisation.
- Lorsque l’utilisateur saisit une adresse e-mail enregistrée et soumet, un message de confirmation s’affiche à l’écran.
- Un courriel contenant un lien de réinitialisation unique est envoyé dans les 5 minutes.
- Le lien de réinitialisation expire 24 heures après sa génération.
- Si l’utilisateur saisit un code incorrect, le système affiche une erreur et autorise une nouvelle tentative.
- Les nouveaux mots de passe doivent respecter les exigences de complexité (8 caractères, 1 chiffre, 1 symbole).
La version améliorée permet aux équipes de QA de rédiger des cas de test spécifiques concernant le délai d’envoi du courriel, l’expiration du lien et les règles de complexité des mots de passe.
🚀 Vers l’avant
Rédiger des critères d’acceptation testables est une compétence qui s’améliore avec la pratique. Elle exige une discipline pour éviter les formulations vagues et un engagement en faveur de la clarté. En se concentrant sur des énoncés objectifs et vérifiables, les équipes de QA peuvent réduire l’ambiguïté et livrer un logiciel de meilleure qualité.
Commencez par auditer vos histoires actuelles. Identifiez les critères qui reposent sur l’opinion ou des métriques floues. Réécrivez-les pour inclure des conditions précises. Encouragez la collaboration entre les rôles afin de garantir une compréhension partagée. Avec le temps, la réduction des défauts et du travail redondant justifiera cet effort.
Souvenez-vous, l’objectif n’est pas seulement d’écrire du texte. L’objectif est de définir la qualité. Lorsque les critères sont précis, le test est efficace, et le produit est fiable.