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 :
| Action | Résultat attendu |
|---|---|
| clique ici | la popup s'ouvre |
| rentre le texte "foo" dans le champ Nom | le 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 :
| action | result |
|---|---|
| On device 1, as user 1, search for people to meet nearby | find the user 2 |
| On device 1, as user 1, send a like to user 2 | a heart should be displayed On device 2, as user 2, a notification should be received |
| On device 2, as user 2, click on the notification | The app opens and display the profile of user 1 |
| On device 2, as user 2, swipe on the left to accept the request | User 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)
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”.
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,…
Pretty! This was an extremely wonderful post. Thank you for providing these details. Vally Sheff Lach
Y a un truc que j’ai du mal à saisir avec le BDD. On valide le comportement mais quid de l’implémentation (libellés, IHM…)? On ne la teste pas ?
Salut Kerqa. Il faut plutôt voir le BDD comme une méthode pour aider l’équipe en entier (développeurs, QA, Produit) à implémenter les features correctement (“do the right things and do it right”). Le BDD donne ensuite des bonnes pratiques pour aider à tester l’implémentation (via le langage Gherkin par exemple) mais ne dit pas exactement comment faire. Les tests doivent ensuite être faits manuellement et/ou automatiquement. Pour la partie automatisation, on peut s’appuyer sur d’autres outils comme cucumber pour passer du test Gherkin à l’implémentation du test. Pour ce qui est des libellés des boutons/texte, il ne faut peut etre pas faire de l’over-engineering : le texte peut etre vérifié manuellement. Pour le comportement de l’IHM, on peut justement utiliser les tests rédigés en gherkin pour nous guider sur l’automatisation