How to Create BDD Gherkin Scenarios With AI

How to Create BDD Gherkin Scenarios With AI

BDD scenarios are useful when product, engineering, and QA need a shared language for expected behavior. A good Gherkin scenario can make requirements easier to discuss, test, automate, and review before a feature ships.

AI can help create BDD scenarios quickly, but the prompt needs structure. If you only ask for "Gherkin tests," the output may be too broad, too repetitive, or disconnected from the actual acceptance criteria.

The goal is not to generate a giant feature file. The goal is to turn requirements into clear Given / When / Then scenarios that describe behavior without inventing product rules.

When BDD Scenarios Are Useful

BDD works best when a feature has business rules that multiple people need to understand.

Good candidates include:

• signup and onboarding flows

• permissions and user roles

• billing and plan limits

• checkout and payment behavior

• workspace or team management

• notifications and emails

• API behavior with business rules

• data import, export, and sync workflows

• high-risk regression areas

BDD is less useful when the requirement is only a visual change, a copy tweak, or a purely technical implementation detail.

Start With the Source Requirement

Before asking AI for Gherkin scenarios, collect the source material:

• user story

• acceptance criteria

• user roles

• business rules

• preconditions

• happy path

• negative cases

• edge cases

• out-of-scope behavior

• related bugs or regression risks

If the requirement is unclear, ask AI to list questions before it writes scenarios.

Prompt Template

Paste this into ChatGPT, Claude, Gemini, or another AI assistant:

Act as a senior QA engineer and BDD reviewer.

Convert the requirement below into Gherkin scenarios using Feature, Background if useful, Scenario, Scenario Outline, Given, When, Then, And, and Examples.

First, list missing assumptions and questions. Then write concise scenarios that map directly to the acceptance criteria.

Rules:

• Do not invent product behavior.

• Use business language, not implementation details.

• Include happy paths, negative cases, permissions, boundary cases, and regression risks.

• Use Scenario Outline only when examples reduce duplication.

• Keep each scenario focused on one behavior.

• Add a short note explaining which acceptance criterion each scenario covers.

Example Requirement

User story:

As a workspace owner, I want to invite teammates by email so they can join my workspace.

Acceptance criteria:

• owners can invite teammates by email

• email address is required

• role must be admin or member

• duplicate pending invitations are blocked

• non-owners cannot invite teammates

• invited teammate receives an email

Example Gherkin Output

Feature: Workspace invitations

Background:

Given a workspace exists

And the workspace owner is signed in

Scenario: Owner invites a teammate with a valid email

Given the owner opens the teammate invitation form

When the owner enters "new.user@example.com"

And selects the "member" role

And submits the invitation

Then a pending invitation should be created

And an invitation email should be sent to "new.user@example.com"

Scenario: Non-owner cannot invite a teammate

Given a non-owner workspace member is signed in

When the member opens the teammate invitation form

Then the member should not be allowed to send an invitation

Scenario Outline: Invalid invitation data is rejected

Given the owner opens the teammate invitation form

When the owner enters "<email>"

And selects "<role>"

And submits the invitation

Then the invitation should be rejected with "<error>"

Examples:

| email | role | error |

| | member | Email address is required |

| not-an-email | member | Enter a valid email address |

| new.user@example.com | owner | Role must be admin or member |

This is a useful first draft, but a QA reviewer still needs to confirm exact error messages, role names, UI permissions, and email behavior.

Ask AI to Create a Coverage Map

After the first draft, ask AI to map each scenario back to the acceptance criteria:

• which acceptance criterion does this scenario cover?

• is it happy path, negative path, edge case, permission case, or regression case?

• what product assumption needs confirmation?

• should this be manual, UI automation, or API automation?

This prevents the Gherkin file from looking complete while missing an important product rule.

Review Before Automation

Before turning BDD scenarios into automated tests, check:

• whether each scenario describes one behavior

• whether the Given / When / Then steps are specific

• whether the expected result is observable

• whether test data can be created reliably

• whether the scenario depends on fragile UI details

• whether the AI invented messages, states, or permissions

• whether repeated scenarios can become a Scenario Outline

• whether high-risk acceptance criteria have negative coverage

BDD is most valuable when it improves shared understanding. If the scenarios are vague, automation will only make the confusion run faster.

Want the ready-made workflow?

AI Test Case Generator Pro is a $9 instant-download pack with BDD/Gherkin prompts, acceptance criteria prompts, Jira and Azure story workflows, API test case prompts, regression prompts, bug-to-regression prompts, CSV-ready templates, example inputs, finished outputs, and a human review checklist.

Use it when you want BDD scenarios that stay tied to real acceptance criteria instead of vague Given / When / Then examples.

Get instant access here:

https://payhip.com/b/SkOtc