Critères d’acceptation Given-When-Then expliqués
Format: Les critères Given-When-Then définissent des comportements logiciels clairs et testables pour une compréhension partagée entre les membres de l’équipe.
Structure: Chaque scénario dans ce format inclut le contexte, l’action de l’utilisateur et le résultat attendu en langage clair.
Bonnes pratiques: Misez sur la simplicité, la collaboration et le niveau de détail pour améliorer la clarté des critères d’acceptation.
Erreurs courantes: Évitez de regrouper trop de scénarios, de rédiger des détails techniques et de négliger les cas limites.
Les critères d'acceptation Given-When-Then (GWT) offrent un moyen simple et testable de décrire le comportement attendu d’un logiciel, afin que développeurs, testeurs et parties prenantes travaillent avec une compréhension commune. Lorsque les critères d'acceptation sont vagues, les équipes perdent du temps à débattre des exigences, construisent des solutions inadéquates et découvrent des lacunes tard dans le développement.
Dans ce guide, je vais décortiquer le format Given-When-Then, présenter des exemples concrets pour différents scénarios courants, comparer cette méthode à d'autres types de critères d’acceptation, et partager les bonnes pratiques qui permettent aux équipes agiles de rédiger des user stories plus claires et efficaces.
Qu’est-ce que les critères d’acceptation Given-When-Then ?
Given-When-Then est un gabarit en trois parties pour écrire des critères d’acceptation dans une user story. Chaque scénario décrit un aspect du comportement attendu en langage courant, accessible aussi bien aux développeurs, aux testeurs qu’aux parties prenantes.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Voici comment cette structure fonctionne :
- Given indique ce qui doit être vrai avant que l’utilisateur ne fasse quoi que ce soit.
- When introduit l’action. C’est ce que fait l’utilisateur ou l’événement déclenché par le système.
- Then révèle le résultat. C’est l’issue qui démontre que le système a réagi correctement.
Comment rédiger des critères d’acceptation Given-When-Then ?
Comment formuler chaque partie afin qu’elle soit solide lors du développement et des tests logiciels.
Given : établir le contexte et les conditions préalables
La clause Given précise ce qui doit être vrai au préalable. Cela inclut l’état du système, le rôle de l’utilisateur, les conditions de données et la configuration environnementale. Un bon Given se veut précis. Évitez « Given l’utilisateur est connecté » lorsque le scénario dépend du rôle. Préférez : « Given un client enregistré, disposant d’un abonnement valide, se trouve sur la page des paramètres du compte. »
Quelques conseils pour rédiger la clause Given :
- Nommez le rôle ou la personne lorsqu’il est pertinent.
- Précisez les conditions système telles que l’état des fonctionnalités, les données ou la connectivité.
- Combinez plusieurs prérequis avec « Et » plutôt que de tout entasser dans une seule phrase.
When : définir l’action ou le déclencheur
La clause When décrit l’action ou l’événement qui déclenche le comportement testé. Elle doit se concentrer sur une seule interaction utilisateur ou un unique événement système, pas une séquence. Utilisez la voix active. Écrivez : « When le client clique sur ‘Appliquer le coupon’ » plutôt que « When le bouton du coupon est cliqué ». Cela dissipe toute ambiguïté quant à l’acteur de l’action.
Gardez cette partie concise. Si vous sentez le besoin d’avoir plusieurs When, vous décrivez probablement deux scénarios distincts. Séparez-les.
Then : spécifier le résultat attendu
La clause Then indique ce que l’utilisateur doit observer ou ce que le système est censé faire après l’action. Décrivez un résultat observable. « Then le tableau de bord s'affiche » n’est pas suffisant. « Then le système affiche le tableau de bord du client en moins de deux secondes » est testable. Précisez par exemple les messages d’erreur, les pages de redirection, les changements de données, les courriels déclenchés ou l’état de l’interface utilisateur.
Utilisez Et pour enchaîner plusieurs résultats lorsqu’une seule action en produit plusieurs de façon observable. Par exemple : « Then la page de confirmation de commande s’affiche » Et « le client reçoit un courriel de confirmation dans les 60 secondes. »
Exemples Given-When-Then
Voici des exemples de critères d'acceptation Given-When-Then pour différents domaines.
Connexion utilisateur
Scénario 1 : Connexion réussie avec des identifiants valides
Given un utilisateur enregistré se trouve sur la page de connexion When l’utilisateur saisit une adresse e-mail valide et le bon mot de passe puis clique sur « Se connecter » Then le système redirige l’utilisateur vers son tableau de bord personnel
La clause Given est volontairement concise ici, car le scénario ne dépend pas du niveau d’abonnement ou du statut du compte. Notez la clause When composée : saisir les identifiants et cliquer sur le bouton forment une seule action logique (soumettre un formulaire de connexion), donc je les regroupe plutôt que de créer un scénario distinct pour chaque frappe.
Scénario 2 : Échec de connexion avec des identifiants invalides
Étant donné qu’un utilisateur enregistré se trouve sur la page de connexion Lorsque l’utilisateur saisit une adresse email valide et un mot de passe incorrect puis clique sur « Se connecter » Alors le système affiche le message « Email ou mot de passe invalide » Et l’utilisateur reste sur la page de connexion
La clause "Alors" précise le texte exact du message d’erreur. La seconde clause « Et » est importante car elle confirme que l’utilisateur n’est pas redirigé par erreur ailleurs.
Panier et passage en caisse
Scénario 1 : Ajouter un article au panier
Étant donné qu’un client consulte la fiche produit d’un article en stock Lorsque le client clique sur « Ajouter au panier » Alors l’icône du panier s’actualise pour afficher un article Et un message de confirmation indique « Article ajouté au panier »
La clause « Étant donné » précise « en stock », car le comportement diffère pour les articles en rupture de stock — qui est un autre scénario.
Scénario 2 : Application d'un code de réduction valide
Étant donné qu’un client a deux articles dans son panier pour un total de $80.00 Lorsque le client saisit le code de réduction « SAVE20 » et clique sur « Appliquer » Alors le système applique une réduction de 20% Et le total du panier est mis à jour à $64.00
Les montants précis en dollars évitent toute interprétation erronée. Ce type de scénario de remise permet de détecter un bug d’arrondi en production où une remise en pourcentage sur un total impair produisait un prix à trois décimales. La précision dans la clause « Étant donné » ($80.00) et celle dans la clause « Alors » ($64.00) est ce qui rend le scénario pertinent.
Réinitialisation du mot de passe
Scénario 1 : Demande de réinitialisation avec un email enregistré
Étant donné qu’un utilisateur se trouve sur la page de connexion Lorsque l’utilisateur clique sur « Mot de passe oublié », saisit une adresse email enregistrée et clique sur « Envoyer » Alors le système affiche « Un lien de réinitialisation a été envoyé à votre adresse email » Et le système envoie un email de réinitialisation du mot de passe dans les 60 secondes
Le « Lorsque » composé ici décrit un seul flux logique : demander la réinitialisation. La contrainte de temps de 60 secondes dans la clause « Alors » est cruciale. Sans celle-ci, un email de réinitialisation reçu vingt minutes plus tard serait techniquement « valide ». Les résultats contraints dans le temps sont l’un des détails les plus souvent oubliés.
Scénario 2 : Utilisation d’un lien de réinitialisation expiré
Étant donné qu’un utilisateur a reçu un email de réinitialisation de mot de passe il y a plus de 24 heures Lorsque l’utilisateur clique sur le lien de réinitialisation présent dans l’email Alors le système affiche « Ce lien a expiré. Veuillez demander une nouvelle réinitialisation. »
La clause « Étant donné » inclut une condition temporelle, forçant ainsi à discuter de la durée de validité du lien.
Validation des formulaires
Scénario 1 : Soumission d’un formulaire avec des champs obligatoires manquants
Étant donné qu’un utilisateur est sur le formulaire d’inscription Lorsque il laisse le champ « Email » vide et clique sur « Envoyer » Alors le système affiche un message d’erreur en ligne « L’email est obligatoire » sous le champ Email Et le formulaire n’est pas envoyé
La clause « Alors » précise où l’erreur apparaît (« sous le champ Email »), et pas seulement qu’elle apparaît.
Scénario 2 : Dépassement de la limite de caractères pour un champ texte
Étant donné qu’un utilisateur remplit le champ « Bio » comportant une limite de 500 caractères Lorsque il saisit 501 caractères Alors le système empêche toute saisie supplémentaire Et un message indique « 500 caractères maximum autorisés »
GWT vs. listes de contrôle vs. cas d’utilisation
Voici d’autres types de critères d’acceptation et dans quelles situations chacun peut être utilisé :
| Aspect | Given-When-Then | Règles sous forme de liste de contrôle | Cas d'utilisation |
|---|---|---|---|
| Structure | Given, When, Then | Liste à puces de règles | Étapes numérotées avec parcours |
| Meilleure utilisation | Scénarios comportementaux, BDD | Règles de gestion, spécifications UI | Fonctionnalités complexes à multiples parcours |
| Forces | Testable, automatisable, riche en contexte | Rapide à rédiger, facile à parcourir | Exhaustif, couvre les cas limites |
| Limites | Verbeux pour des changements simples | Pas de parcours de scénario, difficile à automatiser | Lourde, maintenance lente |
| Public cible | Dév, QA, produit | Produit, design, parties prenantes | Équipes externes, conformité |
| Périmètre | Un seul comportement | Fonctionnalité entière | Fonctionnalité entière |
| Niveau de détail | Trois clauses | Flexible | Préconditions, postconditions, déclencheurs et étapes numérotées |
J’ai constaté que les cas d’utilisation sont particulièrement adaptés lorsqu’il s’agit de documenter un système pour la conformité réglementaire ou de le transférer à un fournisseur externe. Pour le travail quotidien en sprint, le format given-when-then est plus léger et rapide.
Bonnes pratiques Given-When-Then
Voici quelques bonnes pratiques pour utiliser le format GWT efficacement :
- Évitez un langage vague ou ambigu : Au lieu de « Then la page se charge rapidement », écrivez « Then la page de résultats se charge en moins de deux secondes. » Remplacez les adjectifs comme « approprié » ou « pertinent » par des valeurs mesurables. Si cela ne peut pas être testé, reformulez.
- Gardez les scénarios simples et ciblés : Respectez la règle un comportement par scénario. Chaque scénario doit tester une seule chose. Lorsque vous combinez plusieurs actions ou résultats, vous créez des cas de test difficiles à déboguer et à maintenir. Si un scénario comporte plus de deux « and » sous « then », demandez-vous si vous testez un ou deux comportements.
- Organisez une session trois amigos : Une session trois amigos est une conversation courte et ciblée entre un référent produit (owner ou analyste métier), un développeur et un testeur, durant laquelle ils examinent ensemble les histoires à venir avant le début du sprint. Ils rédigent ou affinent ensemble les critères GWT, ce qui évite les retours en arrière.
- Maintenez la cohérence dans la terminologie et le style : Choisissez des termes standards et utilisez-les partout. Si vous parlez de « client » dans un scénario et d’« utilisateur » dans un autre, cela crée de la confusion. Créez un mini-glossaire si besoin. Conservez la même structure de phrase dans vos clauses.
Cinq anti-patterns fréquents
Voici quelques erreurs courantes à éviter lors de la rédaction de critères d’acceptation given-when-then :
- Rédiger des détails d’implémentation au lieu du comportement : Les scénarios comme « Étant donné que l’appel à l’API renvoie un code d’état 200 » décrivent une implémentation technique, et non un comportement utilisateur. Reformulez du point de vue de l’utilisateur : « Étant donné que le catalogue de produits est chargé sur la page d’accueil. » Gardez les détails techniques pour le code d’automatisation des tests.
- Regrouper plusieurs scénarios dans un seul : Un scénario qui teste la connexion, la navigation et le paiement dans un seul bloc est un test d’intégration, pas un critère d’acceptation. Séparez chaque comportement dans son propre scénario. Vous obtiendrez des résultats plus clairs et un débogage facilité.
- Négliger les scénarios négatifs et les cas limites : Les équipes de développement agile écrivent souvent le chemin heureux et oublient ce qui se passe en cas de problème. Pour chaque scénario réussi, demandez-vous : que se passe-t-il si l’entrée est invalide ? Et si le réseau tombe ? Et si les données manquent ? Rédigez au moins un scénario négatif par histoire pour détecter les problèmes avant la mise en production.
- Considérer GWT comme le seul format acceptable : Utilisez GWT pour le comportement, et des checklists pour le reste. Si vous forcez chaque histoire à adopter le format donné-quand-alors, y compris les changements de couleur de bouton, les mises à jour de texte ou la configuration de l’infrastructure, vous obtiendrez parfois des résultats absurdes (ex : « Étant donné que la page d’accueil existe, Quand l’utilisateur la consulte, Alors la police de l’en-tête est de 16px »).
- Rédiger des scénarios isolés : Ne rédigez pas les critères GWT seul. La valeur du format réside dans la discussion qu’il suscite. Si vos scénarios ne sont pas discutés par au moins deux disciplines avant le début du développement, vous utilisez GWT comme format documentaire alors que sa réelle force réside dans la collaboration.
Et maintenant ?
Des critères d’acceptation clairs de type donné-quand-alors ne sont qu’une partie de la réussite d’un projet. Construisez sur cette base avec une adhésion DPM gratuite et accédez à des modèles pratiques, des ressources d’experts et des cadres éprouvés qui aident à transformer des exigences bien définies en livraisons plus fluides et des résultats plus solides.
