Ecrivez de beaux cas de test avec Gherkin

Il existe bien des manières d’écrire des cas de test, mais le langage Gherkin a une place particulière dans mon petit coeur de QA :). Mais avant d’expliquer sa philosophie, analysons d’abord comment on rédige un cas de test habituellement, pour mieux comprendre ce que Gherkin nous apporte.

Les fondamentaux des cas de test

La méthode classique d’écriture des cas de test se base sur un enchaînement de couples (action, résultat). Chacune de ces actions indique précisément toutes les manipulations à faire par le testeur (chaque clic, chaque swipe, chaque texte à rédiger, etc…). Exemple :

ActionRésultat attendu
clique icila popup s'ouvre
rentre le texte "foo" dans le champ Nomle texte s'affiche correctement
Coche la case "bar"la case est cochée
etc...etc...

Cette méthode hyper détaillée assure que n’importe qui peut dérouler la procédure (y compris quelqu’un ne l’ayant pas rédigée). Pour autant, ces procédures sont 

  • longues et pénibles à lire
  • fastidieuses à mettre à jour
  • trop proches de la User Interface (UI)

Ainsi, la moindre petite évolution graphique peut nécessiter la mise à jour de plusieurs lignes de ces procédures, avec toujours un risque d’oubli dans l’une d’elles puisqu’il n’y a pas de commonisation entre les cas de test.

Par ailleurs, ces cas de test sont souvent sauvegardés dans des outils exclusivement  gérés par les QA. Les autres membres de l’équipe n’ont au mieux accès qu’aux compte-rendus de tests (dont ils ne regardent souvent que le pourcentage de KO), ce qui tend à isoler encore davantage les testeurs du reste du monde.

Prenons un exemple avec une application de dating. Un cas de test représentant un match entre 2 personnes pourrait être rédigé comme ceci :

actionresult
On device 1, as user 1, search for people to meet nearbyfind the user 2
On device 1, as user 1, send a like to user 2a heart should be displayed
On device 2, as user 2, a notification should be received
On device 2, as user 2, click on the notificationThe app opens and display the profile of user 1
On device 2, as user 2, swipe on the left to accept the requestUser 1 receives a notification for a match.
User 1 and user 2 should be able to talk to each other

Si cette table est compréhensible puisqu’elle est isolée, on imagine bien que ce ne sera plus le cas avec des centaines de cas de tests (user1 ne like pas user2, user2 n’accepte pas le like de user1, etc…). De plus, on perd en lisibilité car l’information importante (le cas de test de la dernière ligne) est noyée au milieu d’informations de contexte.

Comment rendre notre test lisible ?

La première étape consiste à se distancier de l’UI, et à tester uniquement le fonctionnel. Ainsi, notre exemple précédent aurait pu être rédigé comme ceci :

If user1 sent a like to user2, and user2 accepts this request, then user1 should receive a notification and both users should be able to chat.

Ici, nous n’avons gardé que ce qui était important fonctionnellement (situation initiale, action, résultat), et retiré tout le superflu. De plus, nous nous sommes extraits des choix graphiques (on se moque de savoir s’il faut swiper à gauche, à droite, etc…). Nous gagnons en lisibilité, et une personne arrivant dans l’entreprise pourrait lire simplement ce cas de test et comprendre quel est le but de la fonctionnalité.

Le langage Gherkin

Le langage Gherkin est une mise en pratique du Behaviour Driven Development (BDD). Cette méthode de programmation vise à favoriser la communication entre les membres de l’équipe. (les “3 amigos”, abordé dans un autre article, en sont une autre mise en pratique). Gherkin vise à tester la fonctionnalité, sans écarter la QA des autres acteurs. Il se base sur 4 principaux mots clé (je dis “principaux” car il y en a un peu plus que 4) :

  • Given : décrit la situation initiale, avec une tournure de phrase passive ou au passé
  • When : décrit l’action, avec un verbe d’action au présent
  • Then : décrit le résultat, contient “should” pour indiquer quel est le résultat attendu
  • And : reprend le mot clé de la ligne du dessus (utile si plusieurs conditions à vérifier)
Si nous reprenons l’exemple précédent, nous obtenons ceci :
 
Given user1 sent a like to user2
When user2 accepts the request from user1
Then user1 should receive a notification
And user1 and user2 should be able to chat

Nous avons donc maintenant un cas de test précis et concis. Il peut être compris (et déroulé) aussi bien par un développeur que par un PO. Et le plus fort, c’est qu’il sera automatisable très simplement, et permettra de tendre vers de la documentation vivante (teasing d’un prochain article).

Bonnes pratiques et écueils

Bien que ce ne soit pas obligatoire, je recommande de suivre les temps de conjugaison indiqués ci-dessus : cela vous forcera à respecter une certaine cohérence de rédaction et rendra vos cas de test plus simples à lire. 

Un cas de test est différent d’un parcours utilisateur. On ne veut donc pas enchaîner plusieurs couples (When/Then) dans un même cas de test (on retomberait dans le travers du manque de lisibilité de l’ancienne méthode). 

Veillez à toujours utiliser les mêmes tournures de phrases. N’écrivez pas un jour “Given user1 sent a like to user2”, et le lendemain “Given user1 liked user2”. Un des atouts de ce langage est de pouvoir être automatisé. Si vous changez de phrase pour dire la même chose, vous devrez dupliquer votre code, et le risque d’oubli lors des mises à jour sera à nouveau présent !

Nous testons le fonctionnel, et nos cas de test seront automatisés : essayez donc de trouver des phrases qui seront au bon niveau pour être utilisables dans de nombreux cas de test. En particulier, on ne veut pas de phrase du type “When I click on that button”.

Le petit bonus avec ce langage, c’est de permettre l’homogénéisation du vocabulaire. Dans de nombreuses entreprises, la majorité du vocabulaire pour parler du système est commun, mais il existe toujours des petites différences entre les équipes techniques et non techniques. Grâce à ce langage accessible par tout le monde, nous formalisons à un endroit quel est le mot en face de chaque fonctionnalité. Cela améliore ainsi la communication entre les personnes puisque, petit à petit, tout le monde utilisera vraiment le même vocabulaire.

Référence

Si vous êtes intéressés par le sujet, je vous conseille cette excellente présentation du CTO de HipTest, qui explique en détail le BDD, et son application avec Gherkin : https://www.youtube.com/watch?v=h-j5CL0m3Wg

Ce qu’il faut retenir

  • 3 principaux mots clé : Given, When, Then
  • Est un moyen de tendre vers du Behavior Driven Development
  • Permet l’homogénéisation du vocabulaire 
  • Lors de la rédaction
    • Penser au fonctionnel, pas à la UI
    • Garder les mêmes tournures de phrases
    • Ne pas enchaîner les when,then,when,then,…

2 comments

Leave a Reply

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