← QA Mobile : principes, métier et pratique

Gherkin et BDD : écrire un scénario Given-When-Then

≈ 25 minutes · Prérequis : Écrire un cas de test mobile

Le gain du jour : écrire un scénario de test dans un langage que le métier, le développeur et le testeur lisent tous de la même façon — et qui peut devenir directement un test automatisé.

Le problème que Gherkin résout

En leçon 7, tu as écrit un cas de test très précis : ID, préconditions, étapes, résultat attendu. Cette forme est parfaite pour un testeur qui exécute. Elle l’est beaucoup moins pour discuter avec un product owner : personne du métier ne relit « TC-042, étape 3 » pour valider qu’on a bien compris le besoin.

Le BDD (Behavior-Driven Development, développement piloté par le comportement) part de cette idée : avant de coder, l’équipe — métier, dev, QA — se met d’accord sur des exemples concrets de comportement attendu, écrits en langage naturel structuré. Gherkin est la syntaxe qui sert à écrire ces exemples.

Sa particularité : c’est du texte lisible par un humain non technique, et un format que des outils (Cucumber, Behave, SpecFlow, Cucumber-Appium…) savent exécuter comme un test automatisé. Un même fichier sert de spécification, de cas de test et de script.

La grammaire de base : Given-When-Then

Un scénario Gherkin repose sur trois mots-clés :

Given (Étant donné) — le contexte de départ, l’état du monde avant l’action. C’est l’équivalent des préconditions de la leçon 7.
When (Quand) — l’action déclenchée par l’utilisateur. Une seule action principale par scénario.
Then (Alors) — le résultat observable attendu. Vérifiable, jamais vague.

Deux mots-clés complémentaires :

And (Et) — enchaîne plusieurs lignes du même type sans répéter le mot-clé.
But (Mais) — variante de And, pour une attente négative.

Ces scénarios sont regroupés dans un fichier .feature, introduit par une Feature (la fonctionnalité couverte) :

Feature: Connexion à l'application
  Pour accéder à mon espace personnel
  En tant qu'utilisateur enregistré
  Je veux me connecter avec mes identifiants

  Scenario: Connexion avec des identifiants valides
    Given un compte existe avec l'email "test@exemple.com"
    And l'utilisateur est déconnecté
    And la connexion réseau est active
    When il saisit son email et son mot de passe valides
    And il tape sur "Se connecter"
    Then il est redirigé vers l'écran d'accueil en moins de 3 secondes
    And son nom apparaît dans le menu du profil

C’est exactement le cas de test TC-042 de la leçon 7 — même contexte, même action, même résultat attendu — mais dans une forme qu’un product owner peut relire et corriger lui-même.

Gherkin décrit un comportement, pas une interface

Écrire When il tape sur le bouton bleu en haut à droite de l'écran rend le scénario fragile : le moindre changement de design le casse, et un lecteur métier n’y voit plus le besoin. Écris l’intention (When il se connecte), et laisse les détails d’interface dans le code qui implémente l’étape. C’est la différence entre un scénario qui survit trois ans et un scénario réécrit à chaque refonte.

Scenario Outline : un scénario, plusieurs jeux de données

Quand le même comportement doit être vérifié avec plusieurs valeurs, on ne duplique pas le scénario : on utilise un Scenario Outline (plan de scénario) avec une table d’Examples.

  Scenario Outline: Refus de connexion avec des identifiants invalides
    Given un compte existe avec l'email "test@exemple.com"
    When il saisit l'email "<email>" et le mot de passe "<motdepasse>"
    And il tape sur "Se connecter"
    Then le message "<message>" s'affiche
    And il reste sur l'écran de connexion

    Examples:
      | email             | motdepasse | message                        |
      | test@exemple.com  | mauvais    | Identifiants incorrects        |
      | inconnu@test.com  | valide123  | Identifiants incorrects        |
      |                   | valide123  | L'email est obligatoire        |

Chaque ligne du tableau produit une exécution distincte. C’est la traduction directe des classes d’équivalence et des cas limites : un cas nominal, des cas d’erreur, un cas vide.

Deux autres mots-clés utiles :

Background (Contexte) — les Given communs à tous les scénarios d’un fichier, écrits une seule fois en tête.
@tag — une étiquette posée sur un scénario ou une feature (@smoke, @regression, @android) pour n’exécuter qu’un sous-ensemble de la suite.

Du fichier .feature au test exécuté

Un fichier .feature seul ne teste rien : chaque ligne est reliée à une fonction — la step definition — écrite par un développeur ou un QA automaticien, qui pilote réellement l’application (via Appium, Espresso ou XCUITest, leçon 11).

// Step definition (Cucumber + Appium, illustratif)
Given('l\'utilisateur est déconnecté', async function () {
  await this.app.logout();
});

When('il tape sur {string}', async function (libelle) {
  await this.app.tapByText(libelle);
});

Le métier possède le .feature, la technique possède les step definitions. C’est ce découpage qui fait l’intérêt de Gherkin — et aussi son coût : maintenir cette couche de liaison n’a de sens que si les scénarios sont réellement relus par des non- techniciens. Sinon, un test automatisé écrit directement en code est plus simple.

Vérifie ta compréhension

Dans un scénario Gherkin, à quoi correspond le mot-clé `Given` ?

Quel scénario Gherkin est le mieux écrit ?

Quand utilise-t-on un `Scenario Outline` plutôt qu'un `Scenario` ?

À toi de jouer

Reprends le cas de test rédigé en leçon 7 et réécris-le en Gherkin : une Feature, un Scenario avec Given / When / Then, sans jamais mentionner la position d’un élément à l’écran.
Transforme-le en Scenario Outline avec une table Examples de trois lignes : un cas nominal, un cas d’erreur, un cas limite (champ vide).
Fais relire ton scénario par quelqu’un qui ne connaît pas l’application. S’il ne comprend pas ce qui est testé, le scénario décrit encore trop l’interface et pas assez le comportement.

🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.