Le scénario ne connaît pas l'écran
Il dit « je me connecte », pas « je saisis dans le champ n°3 ». La technique vit dans un objet dédié à chaque page.
BDD et Gherkin
Le BDD n’est pas une syntaxe, c’est une conversation. Given / When / Then n’a d’intérêt que si quelqu’un du métier relit vraiment ce qui est écrit — sinon c’est du code plus verbeux, écrit deux fois.
Prendre rendez-vousCe que ça résout
Dans la plupart des projets, les cas de test vivent dans un outil que seule l’équipe de test ouvre. Le métier valide une spécification, l’équipe teste autre chose, et l’écart se découvre en recette — ou en production.
Le Gherkin déplace la conversation en amont : Étant donné que le restaurant est en configuration « Family Days », quand je consulte la page d’accueil, alors le menu enfant apparaît après la catégorie Menus. Cette phrase, un responsable de campagne la lit, la corrige, et la valide. C’est tout l’intérêt — et c’est perdu si elle est écrite par un développeur pour un développeur.
Le piège
C’est l’écueil que nous avons rencontré de première main, et il ne vient pas de l’outil.
Le scénario Gherkin est rédigé, relu, validé. Le test automatisé, lui, est écrit ailleurs — un fichier de scénario, un script, une configuration. Les deux décrivent la même vérification. Au premier changement, l’un est mis à jour et pas l’autre ; à partir de là, plus personne ne sait lequel fait foi.
La règle que nous appliquons : une seule source, exécutable. Le Gherkin ne documente pas le test, il est le test — chaque phrase est reliée à un pas d’exécution. S’il ne peut pas l’être, mieux vaut assumer un test technique et une spécification séparée, plutôt que d’entretenir deux vérités.
Sur un projet réel, nous avons repris une base de 92 scénarios rédigés à la main en français, décrivant exactement ce que l’automate vérifie — présence, absence, ordre. La question n’était pas de les réécrire, mais de les rattacher à l’exécution.
Page Object Model
Il dit « je me connecte », pas « je saisis dans le champ n°3 ». La technique vit dans un objet dédié à chaque page.
Quand un écran est refondu, on corrige l'objet correspondant. Les cinquante scénarios qui l'utilisent continuent de fonctionner.
La couche technique n'a pas à polluer les phrases : c'est ce qui permet de relire un scénario deux ans plus tard.
Sans ce découpage, une base automatisée grossit puis s’effondre : chaque évolution casse trente tests, l’équipe passe ses semaines à réparer, et l’automatisation finit abandonnée sans que personne n’ose le dire.
Questions franches
Non. Le BDD a un coût — écrire des phrases relues par le métier, maintenir les pas d'exécution — et ce coût ne se justifie que si le métier participe vraiment. Si personne ne relit les scénarios, un test technique bien nommé est plus honnête et moins cher. Nous le disons avant de commencer.
Celui qui parle le langage de votre équipe de développement — Java, .NET, Python, JavaScript. Le choix de l'outil est secondaire : ce qui décide de la réussite est la qualité des pas d'exécution et la discipline sur le vocabulaire.
En interdisant le vocabulaire technique dans les phrases, en limitant le nombre de pas par scénario, et en refusant les scénarios qui décrivent un enchaînement d'écrans plutôt qu'une règle métier. Un scénario qui compte quinze lignes a presque toujours été mal découpé.
Oui, et c'est même son meilleur usage : il remplace le tableur de recette par quelque chose d'exécutable. À condition d'accepter la règle du départ — une seule source de vérité. Un Gherkin qui documente un test écrit ailleurs redevient un tableur, en plus fragile.
Un audit de votre démarche de test, sans engagement, pour savoir où vous en êtes vraiment.
Prendre rendez-vous
French 
English 
Hebrew