Si vous cherchez ce que veut dire « gherkins » et comment vous en servir sans prise de tête : c’est une façon simple d’écrire des scénarios clairs avec Given / When / Then pour décrire un besoin et le tester. En quelques lignes, vous rendez vos User Stories compréhensibles, vérifiables et prêtes à être automatisées.
Mini détail utile : dans tout l’article, on parle d’« utilisateur » pour la personne qui agit, et on écrit les exemples en français pour rester proches des mots du métier.
Qu’est-ce que le gherkin ?
Le gherkin est un langage très simple pour décrire le comportement attendu d’une fonctionnalité. On l’écrit en texte normal, ligne par ligne, en suivant un ordre clair. Chaque ligne commence par un mot clé qui dit ce qui se passe. L’intérêt est double : tout le monde comprend la même chose et on peut transformer ce texte en test.
Un gherkin se lit comme une petite histoire : on pose le contexte, on décrit l’action, puis on dit ce qui doit arriver. Cette forme convient très bien aux User Stories, car elle va droit au but et évite les phrases floues.
Pourquoi l’utiliser pour écrire une User Story ?
Écrire une User Story, c’est dire pour qui, pour quoi, et quel résultat on attend. Le gherkin ajoute une couche de clarté : il supprime l’ambiguïté et force à donner des exemples concrets. Avec lui, une même phrase veut dire la même chose pour tous : produit, design, dev, test, support.
Autre avantage : le gherkin prépare le test dès la rédaction. On gagne du temps plus tard, car les scénarios sont prêts à être rejoués autant de fois que nécessaire. Enfin, il aide à découper : si un scénario devient trop long, c’est souvent qu’il faut le séparer en deux cas plus simples.
Les mots clés à connaître.
Voici les mots que vous verrez toujours. Ils suffisent pour écrire l’essentiel :
- Feature : le titre de la fonctionnalité visée par la User Story. Il annonce la valeur recherchée.
- Scenario : un cas précis de comportement. Une User Story peut avoir plusieurs scénarios.
- Given (Étant donné) : le point de départ, l’état initial, les données déjà en place.
- When (Quand / Lorsque) : l’action de l’utilisateur ou de l’application.
- Then (Alors) : le résultat attendu, visible et vérifiable.
- And / But (Et / Mais) : pour ajouter ou exclure une condition à l’une des étapes.
Un repère simple : une ligne = une étape. Si vous empilez trop de « And », demandez-vous s’il ne faut pas créer un nouveau scénario plus ciblé.
Pour vous y retrouver d’un coup d’œil, ce tableau résume le rôle de chaque mot et donne un micro-exemple :
| Mot clé | Rôle | Exemple court |
|---|---|---|
| Feature | objectif de la fonctionnalité | Feature: paiement par carte |
| Scenario | cas précis à vérifier | Scenario: refuser une carte expirée |
| Given | contexte de départ | Étant donné un panier avec 1 article |
| When | action déclenchée | Quand l’utilisateur saisit une carte expirée |
| Then | résultat attendu | Alors le paiement est refusé |
| And / Mais | condition en plus / en moins | Et un message d’erreur s’affiche |
Astuce : gardez le même vocabulaire partout (par exemple, toujours « utilisateur », pas parfois « client »). Cette cohérence rend les scénarios faciles à relire et à maintenir.
Écrire un scénario pas à pas.
Commencez par une User Story courte. Donnez-lui un titre clair. Ensuite, créez un premier scénario qui couvre le cas principal, celui qui doit réussir. Posez un Given simple : les données de départ. Ajoutez When pour l’action clé. Terminez par Then avec un résultat visible, mesurable, sans jargon.
Restez concret. Évitez les verbes vagues comme « gérer » ou « traiter ». Préférez des verbes précis : « ajoute », « supprime », « affiche », « envoie ». Quand vous écrivez Then, nommez le résultat observable : un message, un état, une sauvegarde, un email envoyé. Si le résultat n’est pas observable, vous ne pourrez pas le vérifier.
Quand le scénario principal tient en quelques lignes, créez des scénarios voisins pour les cas limites : données manquantes, droits insuffisants, format invalide. Chaque scénario doit rester court et lisible. S’il devient long, c’est un signal : il y a peut-être deux comportements à séparer.
Enfin, relisez à voix haute. Si la lecture est fluide et sans hésitation, vous tenez quelque chose de compréhensible pour toute l’équipe.
Exemples concrets pour le web et le mobile.
Imaginons une application avec inscription par email. Voici un scénario de succès très direct :
Feature: inscription par email
Scenario: créer un compte avec un email valide
Étant donné qu’un visiteur ouvre la page d’inscription
Quand il saisit un email valide et un mot de passe fort
Alors le compte est créé
Et un email de confirmation est envoyé
Maintenant un scénario d’erreur :
Scenario: refuser un email invalide
Étant donné qu’un visiteur ouvre la page d’inscription
Quand il saisit « toto@ » comme email
Alors la création du compte est refusée
Et un message « email non valide » s’affiche
Sur mobile, prenons un exemple d’application bancaire :
Feature: virement instantané
Scenario: afficher un solde insuffisant
Étant donné que l’utilisateur a 20 € sur son compte
Quand il tente un virement de 50 €
Alors le virement n’est pas lancé
Et l’application affiche « solde insuffisant »
Ce type d’exemples parle à tout le monde. On sait quoi tester, quoi afficher, et comment réagir.
Erreurs fréquentes et comment les éviter.
- Scénarios trop longs : s’ils dépassent quelques lignes, découpez par comportement. Un scénario = un objectif clair.
- Résultats non observables : « la base est à jour » sans signe concret, c’est fragile. Ajoutez un signe visible : message, état de l’écran, fichier créé.
- Jargon technique : gardez un langage métier. Évitez les termes de code dans Given/When/Then.
- Données magiques : des valeurs étranges sans sens (12345, foo, bar) embrouillent. Choisissez des données qui ressemblent à la vraie vie.
- Ordre cassé : Given puis Then puis When… le lecteur se perd. Respectez l’ordre Given → When → Then.
- Multiples intentions : plusieurs « Then » qui parlent d’objectifs différents font gonfler le scénario. Séparez-les.
- Vocabulaire instable : « utilisateur », « client », « membre » mélangés. Choisissez un mot et tenez-vous-y.
Ces garde-fous gardent vos textes simples, robustes et faciles à relire dans trois mois.
De la User Story au test automatique.
Le gherkin est fait pour être transformé en test. Une fois vos scénarios stables, ils deviennent la base des tests d’acceptation. Chaque ligne Given/When/Then se relie à un pas de test qui exécute l’action ou la vérification. Comme le texte est clair, l’équipe peut partager le travail sans confusions.
Le passage à l’automatisation marche mieux si vous gardez des scénarios rapides et indépendants. Évitez qu’un scénario dépende du résultat d’un autre. Créez le contexte dans le Given de chaque scénario : un utilisateur, un panier, un compte… ainsi, vous pouvez lancer les tests dans n’importe quel ordre.
Pensez aussi à la valeur métier : commencez par automatiser les scénarios qui couvrent le parcours critique. Vous gagnez une alerte rapide en cas de régression. Pour les cas secondaires, attendez d’avoir du temps : mieux vaut un petit lot de tests fiables qu’un gros lot fragile.
Comment démarrer dès aujourd’hui ?
Choisissez une User Story en cours. Écrivez un seul scénario de succès de trois à cinq lignes. Montrez-le à deux personnes de métiers différents. S’ils comprennent la même chose, ajoutez un scénario d’erreur. Ajustez les mots, simplifiez les phrases, remplacez chaque verbe flou par un verbe d’action. Gardez ce rythme : un cas qui réussit, un cas qui échoue. En une session courte, vous aurez une base solide.
Avec cette méthode, les gherkins deviennent un réflexe : clarifier, tester, améliorer. Vos User Stories gagnent en précision, vos tests gagnent en stabilité, et votre produit en bénéficie tout de suite.
