Les bases de la rédaction en Gherkin

Issu de la pratique du Behavior Driven Development (BDD), le langage Gherkin est très souvent associé aux projets agiles car il permet de décrire de manière cohérente les comportements d'un utilisateur.

Il peut être utilisé par le Product Owner, le QA Agile et les développeurs. Son objectif est de créer une documentation homogène grâce à des règles de rédaction communes.

L'un des enjeux majeurs d'un projet agile est d'assurer une communication claire et efficace entre le Product Owner, les développeurs et les QA.

Le Gherkin répond à ce besoin en proposant un langage compréhensible par tous les intervenants du projet.

Les discussions sont alors centrées sur les comportements attendus de l'utilisateur plutôt que sur une succession de règles techniques.

Le langage Gherkin est utilisé par :

• Le Product Owner pour rédiger les User Stories.
• Le QA Agile pour rédiger les critères d'acceptation et les scénarios de test.
• Les développeurs et automaticiens pour automatiser les tests.

Le Gherkin devient ainsi un langage commun à l'ensemble de l'équipe.

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

• Une ligne commence par un mot-clé.
• Un mot-clé représente une étape du comportement utilisateur.
• Une ligne = un mot-clé.

Les trois mots-clés principaux sont utilisés dans cet ordre :

Given
When
Then

• Given (Étant donné) : décrit le contexte initial.
• When (Lorsque) : décrit l'action réalisée par l'utilisateur.
• Then (Alors) : décrit le résultat attendu.

• And (Et) : ajoute une condition.
• But (Mais) : exclut ou précise une condition.

• Feature (Fonctionnalité) : décrit la fonctionnalité ou la User Story.
• Scenario : décrit un comportement attendu spécifique.

Toute personne, même étrangère au projet, doit comprendre le comportement décrit sans avoir besoin d'explications supplémentaires.

Si ce critère est respecté, la rédaction remplit pleinement son objectif.

• 1 User Story = 1 fonctionnalité.
• 1 scénario = 1 comportement.

Si un scénario contient plusieurs ensembles de :

Given
When
Then

il est souvent préférable de le découper en plusieurs scénarios.

• Respecter l'ordre : Given → When → Then.
• Utiliser And et But lorsque nécessaire.
• Éviter le vocabulaire technique et le code.
• Utiliser l'indentation pour améliorer la lisibilité.

Des titres explicites permettent :

• De vérifier rapidement la pertinence du scénario.
• D'identifier les doublons.
• De faciliter la maintenance.

Conseil : limiter le nombre de scénarios à environ 5 par User Story.

Exemple :

Une personne souhaite acheter le tome 1 d'Harry Potter sur un site e-commerce nommé Fleury&Bott.com.

Pour améliorer la lisibilité, le comportement peut être découpé en deux scénarios :

• Recherche d'un produit via la barre de recherche.
• Accès à la fiche produit.

Exemple :

Feature: Recherche d'un livre
 
  Scenario: Recherche du tome 1 d'Harry Potter
    Given que l'utilisateur est sur la page d'accueil
    When il saisit "Harry Potter Tome 1" dans la barre de recherche
    Then les résultats correspondant à sa recherche sont affichés
 
  Scenario: Consultation de la fiche produit
    Given que les résultats de recherche sont affichés
    When l'utilisateur sélectionne le tome 1 d'Harry Potter
    Then la fiche détaillée du produit est affichée

Le langage Gherkin permet :

• D'établir des règles de rédaction communes.
• D'être compris par toutes les parties prenantes.
• De décrire les comportements utilisateurs attendus.
• De faciliter la communication entre les équipes agiles.