Les bases de la rédaction en Gherkin

Contexte et enjeux

Le langage Gherkin est très souvent celui associé aux projets agiles. Il est utilisé à la fois par le PO (Product Owner), le développeur et le QA Agile.

Toutefois, rédiger des user stories, des critères d’acceptation ou des scénarios de test en Gherkin n’est pas toujours aisé. Il peut même rendre la communication moins fluide et plus complexe s’il n’est pas bien maitrisé.

Pour éviter ce biais et maitriser les bases du Gherkin, nous allons explorer les points suivants :

Qu’est-ce que le langage Gherkin ?

A. Pourquoi utiliser le langage Gherkin ?

Assurer une communication claire et efficace entre le PO, les développeurs et le QA agile est l’un des enjeux majeurs de la gestion de projet dans un environnement agile. Chacun utilise son propre langage et cela peut générer des interprétations et/ou des incompréhensions.

Pour répondre à cette problématique, il a fallu réfléchir à un langage universel, pratique, facilement utilisable et compréhensible par tous : le Gherkin.

Mieux se comprendre grâce au langage Gherkin

Ainsi, les communications se font à partir des comportements utilisateurs attendus (parcours utilisateur) plutôt qu’à partir d’une succession de micro-règles s’ajoutant les unes aux autres (fonctionnalité isolée).

Dans une organisation agile, le langage Gherkin sera donc utilisé par tous les acteurs du projet :

  • Le PO pour écrire ses US (user story)
  • Le QA agile pour écrire ses critères d’acceptation et ses scénarios de test
  • Le Développeur pour scripter les tests automatisés

Le Gherkin est donc bien un langage universel de la gestion de projet agile.

B. Comment écrire en Gherkin ?

Le langage Gherkin est structuré par ligne et par mots clés :

  • Une ligne commence par un mot clé
  • Un mot clé correspond à un step du comportement utilisateur
  • Une ligne = un mot clé

Pour rédiger en Gherkin, il est donc nécessaire de connaitre les fonctions reliées aux principaux mots clés :

  • Given (Etant donné que) : décrit le contexte initial
  • When (Lorsque) : décrit l’action faite par l’utilisateur à partir du contexte initial
  • Then (Alors) : décrit le comportement attendu suite à l’action faite par l’utilisateur
  • And (Et) : Ajoute une condition au Given, When ou Then
  • But (Mais) : Exclut une condition au Given, When ou Then

Les mots clés « Given », « When » et « Then » sont donc les fondamentaux de la rédaction du Gherkin. Ils serviront à décrire les comportements utilisateurs attendus.

Néanmoins ces mots clés seront complétés par d’autres selon le contexte et l’interlocuteur :

  • Feature (PO) : correspond à la description de la user story et donc des comportements attendus globaux
  • Scenario (QA agile) : titre clair et concis d’un comportement attendu de la feature pour identifier un scenario de test (y compris les cas non passants)

Pour ceux qui souhaitent aller plus loin sur l’utilisation des différents mots clés, je vous invite à consulter le site de cucumber.

Les principales règles à respecter pour une rédaction claire et efficace en Gherkin

A. La règle d’or de la rédaction en Gherkin

Commençons par la règle d’or d’une bonne rédaction en Gherkin :

La règle d'or

Une personne ne connaissant rien au projet doit pouvoir comprendre le comportement décrit, sans se poser de question, ni avoir des doutes sur l’interprétation.

Si cette règle est respectée, c’est que votre rédaction a rempli tous ses objectifs. Cela correspond en quelque sorte à la Definition of Done de la rédaction en Gherkin.

N’hésitez donc pas à faire relire votre US, vos critères d’acception ou vos scénarios de test à un collègue ou une personne extérieure à votre squad/feature team. Il sera votre meilleur expert qualité sur le sujet ! La cérémonie des 3 Amigos est également un rituel idéal pour procéder à la validation de vos US et critères d’acceptation. 

B. Les 3 règles fondamentales tributaires de la règle d’or

Néanmoins, avant de faire appel à ton beta testeur préféré, la pratique de certaines règles devraient te permettre d’atteindre ton objectif :

1. Un découpage clair :

    • 1 US (user story) = 1 feature : pour limiter les risques de confusion ou d’interprétation, la user storie doit être claire, précise et bien découpée.
    •  
    • 1 scénario = 1 comportement de l’US : comme pour les US, les critères d’acception et/ou les scénarios de test doivent être clairs et compréhensibles. Si votre rédaction contient plus d’un « Given », « When » et/ou « Then« , c’est que la user story, le critère d’acceptation et/ou le scénario peuvent être découpés en plusieurs autres.

2. Une syntaxe claire et lisible

    • 1 « Given » + 1 « When » + 1 « Then » : Ce point est lié au problème du bon découpage cité ci-dessus. Toutefois, il est possible d’ajouter des conditions supplémentaires avec des « And » ou des « But » à chacun de ces 3 mots clés.
    •  
    • Respecter l’ordre « Given » > « When » > « Then«  afin que la rédaction en Gherkin suive l’ordre chronologique du comportement utilisateur attendu.
    •  
    • Introduire un double espace ou une tabulation entre chaque niveau (Feature > Scenario > Step) pour clarifier la lecture.

3. Des titres de scénario clairs et synthétiques

    • Pour vérifier rapidement la pertinence du test si l’on doit sélectionner, ajuster ou prioriser le scope des tests (TNR, priorisation…).
    •  
    • Pour identifier les tests en double : les tests ayant les mêmes objectifs seront ainsi facilement identifiables. Supprimons-les pour se concentrer sur l’essentiel à tester.
    •  
    • Pour identifier facilement les scénarios à modifier : en cas de changement de comportement attendu de l’utilisateur, il sera plus aisé d’identifier les tests qui devront être modifiés.

Dans une optique de clarté, et d’identification rapide des scénarios, il est préférable de ne pas dépasser  5 scénarios de test par user story.

La rédaction en Gherkin par l’exemple

A. Le cas de test en langage standard

Prenons l’exemple d’une personne qui voudrait acheter le tome 1 d’Harry Potter sur un site e-commerce que l’on nommera Fleury&Bott.com

Cas de Test suivant des procédures

Dans le cas présent, nous ne sommes pas dans un scénario de test guidé par le comportement utilisateur, mais dans un cas de test qui suit une procédure de test.

B. Le scénario de test en langage Gherkin

Nous allons donc transformer naturellement le cas de test ci-dessus en scénario de test via le langage Gherkin.

Afin d’être le plus lisible possible, nous allons découper ce cas de test en 2 scénarios distincts :

  1. Un scénario lié au comportement attendu de la search bar
  2. Un scénario lié au comportement attendu pour accéder à la description du produit
Scénario de Test suivant un comportement utilisateur

Ce qu’il faut retenir

Le langage Gherkin, c’est un langage :

Les bonnes pratiques de la rédaction en Gherkin :

PSSST 👀

Cet article vous a plu ❤️ ? N’hésitez pas à le partager pour que d’autres puissent en profiter ! Rejoignez-nous aussi sur Linkedin pour ne rien manquer et suivre notre veille sur les contenus Product & Quality !

Partager sur linkedin
Partager sur twitter
Partager sur email