Azure DevOps – Écrire les critères d'acceptation avec Gherkin

Écrire les critères d'acceptation avec Gherkin

14 Octobre 2020

Il n’est plus à prouver qu’en tant que Product Owner, la bonne compréhension des User Stories par l’ensemble des parties prenantes constitue l’un de vos enjeux majeurs.

Et il est certain aussi qu’aujourd’hui vous maîtrisez le concept de « En tant que , je veux parce que ». Mais quand il s'agit d'écrire les détails à l'intérieur de la US, c’est soit extrêmement détaillé et décousu, soit trop bref. Vos réunions de planification comprennent beaucoup de « Pouvez-vous étoffer cela un peu plus ?», « Attendez, mais que se passe-t-il ici ?», « Comment l'assurance qualité est-elle censée accepter cela ?»

Aujourd'hui, nous allons voir ensemble comment utiliser Gherkin, un framework simple pour décrire ce qui doit être construit.

Langage Gherkin

C’est quoi Gherkin ?

Destiné à l'origine aux développeurs, Gherkin est une approche structurée de l'écriture de tests comportementaux, également appelée Behavior Driven Development (BDD) . Au lieu de tester de petits bouts de code, les tests comportementaux cherchent à suivre le véritable flux de travail de l'utilisateur, comme la connexion ou la demande de remboursement. Cela signifie une concentration sur la façon dont les utilisateurs interagissent avec votre système.

Gherkin est le format des spécifications du Cucumber. C’est un langage spécifique à un domaine, compréhensible par toutes les parties prenantes, créé spécialement pour les descriptions de comportement sans avoir besoin d'entrer dans les détails de la mise en œuvre.

Gherkin a deux objectifs : servir de documentation de votre projet et de squelette de vos tests automatisés. Il est basé sur une grammaire qui existe dans plus de 37 langues. Par conséquent, vous pouvez écrire votre code Gherkin dans plus de 37 langues parlées.

Pourquoi Gherkin ?

Le besoin de Gherkin peut être facilement expliqué par les images suivantes :

Avant Gherkin

Avant Gherkin

Après Gherkin

Après Gherkin

Il s'avère que ce qui ressort de l'écriture de tests comportementaux est identique à l'écriture de User Stories : un aperçu de l'objectif que l'utilisateur souhaite atteindre, des étapes qu'il entreprendra et de la manière dont le produit doit répondre.

Gherkin peut donc être considéré comme étant le framework idéal pour écrire des User Stories car il donne une approche cohérente pour examiner tous les scénarios, apporte la définition de Terminé et fournit des critères d'acceptation précis.

Syntaxe de Gherkin

Gherkin est un langage orienté ligne, tout comme YAML et Python. Chaque ligne est appelée step et commence par un mot-clé.

Gherkin utilise un ensemble de mots-clés spéciaux pour donner une structure et une signification aux spécifications exécutables. Et comme mentionné ci-dessus, chaque mot-clé est traduit dans de nombreuses langues parlées ; dans cette référence, nous utiliserons le Français.

Les principaux mots clés utilisés dans Gherkin sont :

  • Fonctionnalité
  • Contexte
  • Scénario
  • Donné
  • Quand
  • Puis
  • Et
  • Mais
  • Exemples de plan de scénario

Il existe également quelques mots clés secondaires :

  • """ (Doc Strings)
  • | (Data Tables)
  • @ (Tags)
  • # (Commentaires)

Les commentaires ne sont autorisés qu'au début d'une nouvelle ligne, n'importe où dans le fichier d'entités. Ils commencent par zéro ou plusieurs espaces, suivis d'un signe dièse (#) et d'un texte.

Des espaces ou des tabulations peuvent être utilisés pour l'indentation. Le niveau d'indentation recommandé est de deux espaces.

Un document Gherkin a une extension .feature et c’est un simple fichier de test avec une extension sophistiquée. Cucumber lit le document Gherkin et exécute un test pour valider que le logiciel se comporte selon la syntaxe déclaré dans le script Gherkin.

Fonctionnalité :

Le fichier doit avoir l'extension .feature et chaque fichier ne doit avoir qu'une seule fonctionnalité. Le mot-clé de fonctionnalité étant « fonctionnalité: » et doit être suivi par le nom de la fonctionnalité.

Scénario :

Chaque fichier de fonctionnalités peut avoir plusieurs scénarios et chaque scénario commence par « Scénario : » suivi du nom du scénario.

Contexte :

Le mot-clé contexte (background en Anglais) vous aide à ajouter du contexte au scénario. Il peut contenir certaines étapes du scénario, mais la seule différence est qu'il doit être exécuté avant chaque scénario.

Pour chaque User Story, un ensemble de scénarios (de 1 à environ 4 au maximum) décrit le comportement attendu en Gherkin :

Etant donné que ‘contexte initial’
Quand ‘un événement’
Alors ‘un certain résultat’

Exemples

Exemple 1

Un exemple familier pour les chefs de produit :

Fonctionnalité : Connexion utilisateur
En tant qu'utilisateur, je souhaite me connecter pour voir mes campagnes marketing

Scénario: l'utilisateur fournit le nom d'utilisateur et le mot de passe corrects
Étant donné que je suis sur la page de connexion
Lorsque j'entre mon nom d'utilisateur et mon mot de passe correctement
et que je clique sur `` Se connecter ''
Alors je suis redirigé vers le tableau de bord

Scénario: L'utilisateur ne fournit PAS le nom d'utilisateur correct et mot de passe
Étant donné que je suis sur la page de connexion
Lorsque je saisis mon nom d'utilisateur et mon mot de passe de manière incorrecte
et que je clique sur "Connexion"
Alors le message d'erreur "Désolé, nom d'utilisateur ou mot de passe incorrect" s'affiche.

Gherkin suit une syntaxe très spécifique :
Scénario -> Étant donné -> Lorsque -> Alors

Scénarios : toutes les actions qu'un utilisateur pourrait entreprendre (y compris une mauvaise saisie)
Etant donné : définit le contexte. Sur quelle page sommes-nous et dans quel état sommes-nous ? L'utilisateur est-il un administrateur ? Connecté ? A créé une campagne ?
Lorsque : quelles actions l'utilisateur exécute. Quel événement s'est produit ?
Alors : que devrait faire le système en réponse ? Quel est le résultat attendu ?

Exemple 2

Fonctionnalité : Avoir un compte bancaire
Afin d'offrir aux utilisateurs la possibilité d'avoir un compte
Etant donné que je suis inscrit
Je dois être capable d'ajouter ou de retirer de l'argent

Scénario : Ajouter de l’argent
Etant donné que je suis un utilisateur connecté
Et que j'ai un compte bancaire
Et que le solde de mon compte est de 10 euros
Lorsque j'ajoute 5 euros sur mon compte
Alors mon solde doit être de 15 euros

Plan du Scénario :
Etant donné que j'ai un compte bancaire
Et que le solde de mon compte est de euros
Lorsque j'ajoute euros sur mon compte
Alors mon solde doit être de euros

Examples :

soldeInitial montant soldeFinal
5 10 15
20 20 40
20 7 27
0 10 10

Vous avez certainement remarqué dans ce dernier exemple, l’utilisation d’un tableau d’injection de valeurs de tests, pour que cela reste fonctionnel, il suffit de préciser le terme « Plan du scénario » (ou Outline en anglais). Celui-ci permet donc de tester ce scénario pour les 4 cas de figures présentés.

Ce qu’il faut éviter de faire ?

Ne mentionnez aucun détail technique, comme les colonnes de base de données ou les classes CSS. L'accent doit être mise sur l'utilisateur et ses comportements. Efforcez-vous de garder les détails techniques en dehors de votre code Gherkin, sauf si vous écrivez une API. Même dans ce cas, il ne doit pas y avoir de référence à COMMENT le code doit être écrit.

Meilleures pratiques d'utilisation de Gherkin

  • Chaque scénario doit s'exécuter séparément
  • Chaque fonctionnalité doit pouvoir être exécutée séparément
  • Les informations sur les étapes doivent être affichées indépendamment
  • Connectez vos scénarios à vos besoins
  • Gardez une trace complète des scénarios à inclure dans un document d'exigence
  • Créez des étapes modulaires et faciles à comprendre

Avantages et inconvénients de Gherkin

Avantages

  • Gherkin est assez simple pour que les non-programmeurs le comprennent
  • Les programmeurs peuvent l'utiliser comme une base très solide pour démarrer leurs tests
  • Il rend les User Stories plus faciles à implémenter
  • Il cible les besoins de l'entreprise
  • Une part importante des spécifications fonctionnelles est écrite sous forme de User Stories
  • Vous n'avez pas besoin d'être un expert pour comprendre le petit jeu de commandes Gherkin
  • Gherkin associe les tests d'acceptation directement aux tests automatisés
  • Le style d'écriture des cas de tests est plus facile à réutiliser dans le code d'autres tests

Inconvénients

  • Il nécessite un niveau élevé d'engagement et de collaboration
  • Il peut ne pas fonctionner correctement dans tous les scénarios
  • Des tests mal rédigés peuvent facilement augmenter les coûts de maintenance des tests

Résumé

  • Gherkin est le format des spécifications de Cucumber
  • Gherkin est un langage orienté ligne, tout comme YAML et Python
  • Le script de Gherkin relie le concept humain de cause à effet au concept logiciel d'entrée / processus et de sortie
  • Fonctionnalité, arrière-plan, scénario, donné, quand, alors et mais sont utilisés de manière importante dans Gherkin
  • Dans le Cucumber Gherkin, chaque scénario doit s'exécuter séparément
  • Le plus grand avantage de Gherkin est qu’il est assez simple pour que les non-programmeurs le comprennent
  • Malgré sa force mais il peut ne pas fonctionner correctement dans tous les types de scénarios




Consultez nos Formations sur
Méthodes Agiles, User Stories, Azure DevOps
ou faites-nous part de vos remarques sur cet article

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *