The script does not know the screen
He says «I log in», not «I type in field #3». The technology lives in an object dedicated to each page.
BDD and Gherkin
BDD is not a syntax, it is a conversation. Given / When / Then is only useful if someone in the field actually reviews what is written — otherwise it's just more verbose code, written twice.
Make an appointmentWhat it solves
In most projects, test cases live in a tool that only the testing team opens. The business validates a specification, the team tests something else, and the gap is discovered during user acceptance testing—or in production.
The Gherkin moves the conversation upstream: Given that the restaurant is in «Family Days» configuration, when I view the home page, then the kids' menu appears after the Menus category. This sentence is read, corrected, and approved by a campaign manager. That is the whole point—and it is lost if it is written by a developer for a developer.
The trap
This is the pitfall we encountered firsthand, and it does not come from the tool.
The Gherkin scenario is written, reviewed, and validated. The automated test itself is written elsewhere—a scenario file, a script, a configuration. Both describe the same verification. At the first change, one is updated and not the other ; from that point on, no one knows which one is authentic.
The rule we apply: single source, executable. Gherkin does not document the test; it is The test — every sentence is linked to an execution step. If it cannot be, it is better to assume a technical test and a separate specification, rather than maintaining two truths.
On an actual project, we took over a database of 92 hand-written scenarios in French, describing exactly what the PLC checks — presence, absence, sequence. The question was not to rewrite them, but to link them to the execution.
Page Object Model
He says «I log in», not «I type in field #3». The technology lives in an object dedicated to each page.
When a screen is redesigned, the corresponding object is corrected. The fifty scenarios that use it continue to work.
The technical layer shouldn't pollute the sentences: that's what makes it possible to read a script again two years later.
Without this partitioning, an automated base grows and then collapses: every change breaks thirty tests, the team spends its weeks fixing them, and automation ends up abandoned without anyone daring to admit it.
Frank questions
No. BDD has a cost—writing sentences reviewed by the business, maintaining execution steps—and this cost is only justified if the business actually participates. If no one reviews the scenarios, a well-named technical test is more honest and cheaper. We say this before starting.
The one who speaks your development team's language—Java, .NET, Python, JavaScript. The choice of tool is secondary: what determines success is the quality of the execution steps and discipline regarding vocabulary.
By banning technical vocabulary in sentences, limiting the number of steps per scenario, and rejecting scenarios that describe a sequence of screens rather than a business rule. A scenario that is fifteen lines long has almost always been poorly broken down.
Yes, and that’s actually its best use: it replaces the spreadsheet with something that can be executed. Provided you accept the basic rule—a single source of truth. A Gherkin that documents a test written elsewhere just becomes another spreadsheet—and a more fragile one at that.
A no-obligation audit of your testing process to find out where you really stand.
Make an appointment
English 
French 
Hebrew