# Écrire des scénarios Gherkin avec un product owner qui ne lit pas le code > Une méthode d'atelier pour rédiger des scénarios Gherkin à deux, sans que le product owner ait besoin d'ouvrir un éditeur de code. - Auteur : WordPress Développement - Publié le : 2022-10-18 - Mis à jour le : 2022-10-18 - Catégorie : Tests - URL : https://www.wpmoderne.fr/tests/scenarios-gherkin-product-owner-atelier/ ## L’essentiel - Un vocabulaire commun avant la syntaxe - Des post-it avant les fichiers .feature - Le product owner relit, le développeur formalise Comment amener un product owner à formuler lui-même les critères d'acceptation d'une fonctionnalité, sans qu'il touche à un fichier `.feature` ni qu'il apprenne la syntaxe Gherkin de mémoire ? La question mérite d'être posée, parce que la réponse habituelle — laisser le développeur rédiger seul les scénarios après coup — produit des tests qui valident ce que le code fait, pas ce que le métier attend. Sur un projet de plateforme d'inscription à des ateliers associatifs, nous avons testé un format d'atelier en deux temps : d'abord une discussion sans syntaxe, ensuite une formalisation guidée. Le résultat a dépassé nos attentes, autant sur la qualité des scénarios que sur l'implication du product owner dans la suite du projet. ## Pourquoi la rédaction Gherkin classique échoue avec un non-développeur Donner un gabarit `Étant donné / Quand / Alors` à quelqu'un qui n'a jamais écrit de test revient à lui donner un moule sans lui expliquer la matière qu'on y coule. Le product owner produit alors des phrases syntaxiquement correctes mais vides de sens métier, ou pire, il abandonne et laisse le développeur écrire à sa place — ce qui annule l'intérêt du BDD (Behavior-Driven Development) : faire converger la compréhension avant le code. Le problème n'est pas la syntaxe elle-même, plutôt simple, mais l'ordre des opérations. On demande à quelqu'un de formaliser une règle avant même qu'elle soit clairement énoncée à l'oral. ## Le déroulé d'atelier qui fonctionne > L'essentiel à retenir : Un vocabulaire commun avant la syntaxe ; Des post-it avant les fichiers .feature ; Le product owner relit, le développeur formalise L'atelier se déroule en trois blocs de vingt à trente minutes, avec un tableau blanc ou des post-it, jamais d'ordinateur ouvert au départ : 1. Le product owner raconte le parcours utilisateur à voix haute, sans structure imposée. Le développeur note les cas particuliers qui surgissent naturellement (« et si la session est complète ? »). 2. Ensemble, on classe ces cas en exemples concrets avec des valeurs réelles : un nom d'atelier, un nombre de places, une date. Pas d'abstraction du type « un utilisateur », mais « Camille s'inscrit à l'atelier poterie du 14 mars ». 3. Le développeur reformule chaque exemple au format Gherkin devant le product owner, qui valide ou corrige immédiatement la formulation. ### Un exemple de transformation L'échange oral « si l'atelier est complet, il ne doit plus pouvoir s'inscrire, mais on doit lui proposer la liste d'attente » devient : ``` Scénario : Inscription refusée sur un atelier complet avec proposition de liste d'attente Étant donné que l'atelier "Poterie du 14 mars" affiche 0 place restante Quand Camille tente de s'inscrire à cet atelier Alors le formulaire d'inscription est remplacé par un bouton "Rejoindre la liste d'attente" Et aucune ligne n'est créée dans la table des inscriptions confirmées ``` ## Ce que le product owner apporte que le développeur ne voit pas Sur ce projet, le product owner a soulevé deux règles que personne n'avait anticipées : la liste d'attente devait respecter l'ordre d'arrivée même en cas de double clic, et un bénévole inscrit à plus de trois ateliers le même mois devait recevoir un message d'alerte plutôt qu'un blocage. Ces règles n'étaient écrites nulle part ; elles vivaient dans sa tête depuis des années de gestion manuelle. Sans l'atelier, ces cas seraient apparus en recette, ou pire, en production, sous forme de tickets de support. ## Les pièges à éviter côté développeur - **Reformuler trop vite** : si le développeur traduit en Gherkin avant que l'exemple soit stabilisé à l'oral, le product owner valide par politesse sans vraiment comprendre ce qui a été écrit. - **Multiplier les scénarios abstraits** : un scénario avec des valeurs génériques (« un utilisateur », « un produit ») perd toute force de conviction pour quelqu'un qui pense en cas réels. - **Vouloir tout couvrir en une session** : au-delà de douze à quinze scénarios, l'attention retombe et la qualité de relecture chute nettement. > Un scénario que le product owner ne peut pas relire à voix haute sans hésiter n'est pas encore prêt à être automatisé. ## En résumé La rédaction Gherkin à deux ne demande pas au product owner d'apprendre une syntaxe, elle demande au développeur d'accepter de retarder la formalisation jusqu'à ce que l'exemple métier soit limpide à l'oral. Le gain se mesure moins en nombre de scénarios qu'en absence de surprises pendant la recette : sur ce projet, aucune des douze règles validées en atelier n'a nécessité de réécriture après la mise en ligne.