The takeaway in 30 seconds

• Gherkin is a plain-text, structured language that describes software behavior in human-readable format, making automated test scenarios understandable to non-technical stakeholders including business owners, product managers, and executives.
• Gherkin is the foundation of behavior-driven development (BDD), linking high-level business requirements to executable test automation code through a shared language that both technical and non-technical team members can read and contribute to.
• The core Gherkin keywords are Given, When, Then, And, But, and Background. Each keyword defines a specific step in a test scenario, creating a consistent structure that maps to automation code.
• Gherkin originates from Cucumber, an open-source BDD framework that supports multiple programming languages and translates coded test logic into human-readable format without losing implementation details.
• Ranorex by Sembi supports Gherkin-based test automation, integrating with DesignWise to allow teams to structure test cases in plain-language Gherkin syntax and execute them as part of reliable, automated testing workflows.

What is Gherkin testing?

Gherkin testing is the practice of writing automated software test scenarios using the Gherkin language, a plain-text, structured format that describes expected system behavior in human-readable terms. Gherkin serves as the bridge between business requirements and technical test automation, enabling product owners, developers, and QA testers to work from a shared understanding of how the software should behave.

Unlike traditional test scripts written in programming languages that only developers can read, Gherkin scenarios are written in natural language that business stakeholders can understand and verify. Each scenario describes a real-world user action or business rule, making test cases a form of living documentation that stays aligned with the software system as it evolves.

Gherkin testing is the core of behavior-driven development (BDD), a software development approach that prioritizes collaboration between technical and non-technical team members around shared, executable specifications.

What is the Gherkin language format?

Gherkin is a plain-text, simply structured language designed to be easy for non-programmers to learn and understand while remaining sophisticated enough to drive automated test execution. It describes software behavior through a consistent syntax of keywords and plain-language statements that link directly to automation code.

How Gherkin works

Gherkin feature files describe what the software should do under specific conditions. Each feature file contains one or more test scenarios, and each scenario is built from a sequence of steps using Gherkin keywords. These steps are then matched to step definition files, which contain the automation code that executes each step.

This structure creates a direct link between high-level business requirements and the automation code that validates them. When the software changes, teams update the Gherkin scenarios to reflect the new expected behavior, keeping the documentation and the tests synchronized.

Gherkin feature files

Every test in Gherkin lives inside a feature file. Feature files have a unique name and describe a specific area of functionality. Each feature file can contain multiple test scenarios, and each scenario represents what will happen when a user interacts with the software in a particular way.

Between test runs, step definition files store mappings between Gherkin steps and the automation code that executes them. These mappings can be reused across multiple scenarios, reducing duplication and keeping background scenario logic consistent across the same scenario types.

Gherkin scenarios

Gherkin scenarios describe specific interactions between users and the software. For example, a scenario might describe what happens when a user attempts to log in with valid credentials, invalid credentials, or no credentials at all.

Each scenario follows the same structure, making it easy for anyone on the team to understand what is being tested, what the expected outcome is, and whether the test passed or failed.

Gherkin syntax

Gherkin uses a line-oriented syntax where each line begins with a keyword that defines the role of that step in the scenario. The syntax builds a bridge between the real-world concept of cause and effect and the software concept of input, process, and output.

Basic Gherkin syntax structure

Feature: [The title of the feature being tested]

  Scenario: [The name of the specific test scenario]

    Given [the initial context or state]
    When [the action or event that occurs]
    Then [the expected result or outcome]

Complete example

Feature: User login

  Scenario: Successful login with valid credentials

    Given the user is on the login page
    When they enter a valid username and password
    Then they should be redirected to their dashboard

  Scenario: Failed login with invalid credentials

    Given the user is on the login page
    When they enter an invalid username or password
    Then they should see an error message
    And the login form should remain visible

This example demonstrates how Gherkin expresses expected behaviors in a clear, business-readable way while remaining directly executable as an automated test. The same feature file is readable by a product manager verifying business requirements and by a developer connecting steps to automation code.

Gherkin keywords explained

Gherkin uses a small set of keywords that define the role of each step in a test scenario. Understanding these keywords is essential for writing effective Gherkin scenarios and connecting them to automation code.

Given

Given defines the initial context or precondition for the test scenario. It describes the state the system is in before any action is taken.

Example: Given the user is on the login page

Given establishes what a user sees or what state the system is in before the test begins. In a login scenario, Given might describe that the user can see the login screen.

When

When describes the action or event that triggers the behavior being tested. It defines what the user does or what happens to the system.

Example: When they enter valid credentials and click the login button

When captures user input, interactions, or system events. If there is an error in the code, the language in the test results may not feel quite right, signaling that something went wrong during this step.

Then

Then describes the expected outcome or result. It defines what the user should see or experience after the When action occurs.

Example: Then they should be redirected to their dashboard

Then verifies that the system behaved as expected. It shows what the user should look out for and confirms the outcome of the action.

And

And extends or adds conditions to a previous step. It is used when a Given, When, or Then step has multiple conditions that need to be expressed separately.

Example:

Given the user is on the login page
And the login form is visible
When they enter valid credentials
And click the login button
Then they should be redirected to their dashboard
And a welcome message should be displayed

But

But adds an adverse or negative condition to a step. It expresses that a specific condition should not be true alongside other expected outcomes.

Example:

Then they should be redirected to their dashboard
But the error message should not be displayed

Background

Background defines steps that are shared across multiple scenarios in the same feature file. It is used to avoid repeating common setup steps in every scenario.

Example:

Feature: User account management

  Background:
    Given the user is logged in
    And they are on the account settings page

  Scenario: Update email address
    When they enter a new email address
    Then their email should be updated

  Scenario: Change password
    When they enter a new password
    Then their password should be updated

Background is particularly useful for features like online shopping where multiple scenarios share the same setup, such as adding items to a cart or completing payment processes.

Gherkin and Cucumber

Gherkin originates from Cucumber, an open-source BDD testing framework that supports multiple programming languages. Cucumber gives teams the ability to translate coded test logic into a format that most people can read and interpret without losing any important implementation details.

How Cucumber uses Gherkin

In the Cucumber framework, Gherkin feature files define the test scenarios in plain language. Cucumber matches each Gherkin step to a step definition written in a programming language such as Java, Ruby, Python, or JavaScript. When tests run, Cucumber executes the step definitions while reporting results in the human-readable Gherkin format.

Benefits of using Gherkin and Cucumber together

• Easy to understand and adopt for teams at all technical levels
• Helps programmers build a strong foundation for automated tests grounded in business requirements
• Makes user errors easier to identify and correct
• Non-technical personnel including business stakeholders and executives can follow test results
• Focuses teams on business requirements and expected behaviors rather than implementation details
• Functional specifications can be written as user stories, improving readability across the organization
• Plain-language commands are understood by most people without technical training
• Directly linked to automated tests for executable specifications
• Easy to integrate into testing frameworks and tools including Ranorex

Together, Gherkin and Cucumber create living documentation, keeping feature files and test cases synchronized with ongoing development so that testing remains transparent and consistent for every team member.

Gherkin use cases in automated testing

Gherkin can be applied across almost every type of automated software test. The goal in every case is to bring software to market faster with fewer bugs while keeping test results accessible to everyone on the team.

Functional testing

In functional testing, Gherkin scenarios describe whether the software is working as it should under specific conditions. Coders do not have to translate results for others. Test scenarios show shareholders, testing teams, and developers exactly where they are in the development process. Those who are not technically inclined can still understand what was tested and what the outcome was.

Regression testing

Gherkin makes regression test scenarios readable across team boundaries. When new code changes are introduced, existing Gherkin scenarios can be re-executed to verify that previously working functionality has not been broken. The human-readable format makes it easy to communicate regression test coverage to non-technical stakeholders.

Integration with DesignWise and Ranorex

DesignWise by Sembi allows teams to structure optimized test cases using plain-language Gherkin syntax. These test cases can then be exported and executed within Ranorex by Sembi as part of automated testing workflows. This integration ensures that automation code remains aligned with executable specifications while maintaining a shared understanding across technical and non-technical team members.

Continuous testing in agile and DevOps environments

Because each Gherkin scenario represents a specific user behavior or business rule, Gherkin-based tests can be continuously executed as the software evolves. This supports agile and DevOps development cycles where code changes are frequent and fast feedback is essential.

Gherkin best practices

Following established best practices keeps Gherkin files effective, maintainable, and aligned with living documentation principles.

Use concise, descriptive scenario names. Each scenario name should clearly describe what is being tested without requiring the reader to read the full steps to understand the purpose.

Write steps in the same voice and tense. Consistent language across all scenarios makes feature files easier to read and reduces ambiguity for both technical and non-technical team members.

Reuse Background scenarios for common setup steps. Any steps that appear in multiple scenarios in the same feature file should be moved to a Background block to avoid duplication and keep files clean.

Review and refactor outdated scenarios regularly. As software evolves, some scenarios become outdated. Regular review ensures that feature files reflect the current expected behavior of the system rather than past states.

Keep scenarios focused on one behavior. Each scenario should test one specific behavior or user action. Scenarios that test multiple behaviors simultaneously are harder to maintain and harder for non-technical readers to follow.

Write steps from the user’s perspective. Steps should describe what the user sees or does, not what the code does internally. This keeps scenarios readable for business stakeholders and focused on user-facing outcomes.

Keep documentation simple enough for non-technical stakeholders but specific enough for developers. This balance ensures that feature files serve as genuine living documentation rather than either oversimplified summaries or technical specifications that only developers can use.

Gherkin in behavior-driven development (BDD)

Behavior-driven development is a software development approach that aligns product owners, developers, and testers around shared, human-readable specifications of expected system behavior. Gherkin provides the language foundation for BDD by creating a format that all three groups can read, write, and verify.

How BDD with Gherkin works

In a BDD workflow, the process begins before any code is written. Product owners and business stakeholders describe the desired behavior of the software in Gherkin scenarios. Developers and testers review these scenarios, clarify edge cases, and connect each Gherkin step to automation code. When the code is written, the Gherkin scenarios are executed as automated tests to verify that the implementation matches the specification.

This approach ensures that development effort is focused on behaviors that matter to the business and that the resulting software can be verified against a clear, shared specification.

BDD with Ranorex and DesignWise

Ranorex by Sembi supports integration with DesignWise for Gherkin-based BDD workflows. DesignWise helps teams structure test cases in plain-language Gherkin syntax, which Ranorex then executes as part of automated testing workflows. This creates a connected, end-to-end testing solution that supports BDD principles and helps teams deliver high-quality software faster.

How Ranorex supports Gherkin testing

Ranorex by Sembi is a comprehensive test automation platform that supports behavior-driven development through Gherkin integration. Teams can write test scenarios in Gherkin syntax using DesignWise, then execute those scenarios within Ranorex as reliable, automated tests.

Ranorex supports codeless automation through capture-and-replay for teams that prefer not to write code, and a full IDE for developers who want to write and customize tests in standard programming languages. Both approaches are compatible with Gherkin-based BDD workflows.

Ranorex by Sembi is part of the Sembi portfolio of software quality and security tools, which also includes DesignWise for test case design, DashO for application security, and Kiuwan for code quality and vulnerability scanning.

Start your free 14-day trial of Ranorex and see how easily you can integrate Gherkin-based scenarios into your automated testing workflow.

Frequently Asked Questions About Gherkin Testing

What is Gherkin in software testing?
Gherkin is a plain-text, structured language used in software testing to describe expected system behavior in human-readable format. It serves as the foundation for behavior-driven development (BDD), creating a shared language that both technical and non-technical team members can read and contribute to. Gherkin scenarios describe real-world user actions and expected outcomes using keywords including Given, When, Then, And, But, and Background. These scenarios link directly to automation code, making them executable specifications rather than static documentation.

What are Gherkin keywords?
Gherkin keywords are the structured commands that define the role of each step in a test scenario. Given establishes the initial context or precondition before a test begins. When describes the action or event that triggers the behavior being tested. Then defines the expected outcome after the action occurs. And extends or adds conditions to any previous step. But adds adverse or negative conditions to a step. Background defines setup steps shared across multiple scenarios in the same feature file. Together these keywords create a consistent, readable structure that maps directly to automation code.

What is the difference between Gherkin and Cucumber?
Gherkin is the plain-text language used to write test scenarios in human-readable format. Cucumber is the open-source BDD testing framework that reads Gherkin feature files, matches each step to a step definition written in a programming language such as Java, Ruby, or Python, and executes the tests. Gherkin defines what should happen. Cucumber defines how the test is executed. Gherkin without Cucumber is documentation. Cucumber without Gherkin uses a different format for test definitions. Together they create a BDD framework where test specifications are both human-readable and machine-executable.

What is behavior-driven development (BDD)?
Behavior-driven development is a software development approach that aligns product owners, developers, and testers around shared, human-readable specifications of expected system behavior. BDD begins before code is written, with business stakeholders describing desired behaviors in plain language. These descriptions become executable test scenarios using a language like Gherkin. Developers connect each scenario step to automation code, and the scenarios are executed as automated tests to verify that the implementation matches the specification. BDD reduces miscommunication between technical and non-technical team members and ensures development effort focuses on behaviors that matter to the business.

What are executable specifications in Gherkin?
Executable specifications in Gherkin are test scenarios written in plain language that describe expected system behavior while simultaneously linking to automation code that can verify that behavior. They bridge the gap between business goals and technical implementation by expressing requirements in a format that both stakeholders and developers can read and act on. Unlike static documentation that becomes outdated as the