Gherkin
Automation Frameworks
Open source
<What you get/>
Scenarios written at the level of intent, readable by the people who define correctness
A shared glossary so the same behaviour is described the same way across the suite
A rewrite of existing step-by-step scenarios into outcome-based ones
A deliberate cap on scenario count so the specification stays reviewable
What it is
Gherkin is the Given-When-Then syntax behind behaviour-driven development. It is deliberately constrained so that a business stakeholder can read a scenario without training, while remaining structured enough for a machine to execute. Used well it becomes the single definition of expected behaviour; used carelessly it becomes a verbose way of writing test scripts.
How PerfectQA uses Gherkin
Gherkin is the notation we use when a specification needs to be agreed before it is built. We treat it as a writing discipline rather than a tool: scenarios stay at the level of intent, one behaviour each, in the vocabulary the business already uses. The failure we most often inherit is Gherkin written as instructions — ‘click the button, enter the value, click submit’ — which is unreadable to the stakeholders it was supposed to serve and brittle to every UI change. We rewrite those to describe outcomes instead of interactions. We keep a shared glossary so the same concept has one name across scenarios, and we push back on scenario counts, because a hundred readable scenarios stop being read. The value is agreement before the build, and that only survives if the scenarios stay short enough to review.
Category
Automation Frameworks
In our stack
6 years
Projects
20 delivered
Where we’ve put it to work
Frequent questions
Is Gherkin a tool?
How detailed should a scenario be?
Can we reuse steps across scenarios?
Our existing feature files are unreadable. Can they be fixed?
Every stack is different
Tell us yours, and we’ll show you where this fits
