·
9 min
BDD Testing: From Shared Example to Executable Test
Roman Kirchmeier - Autemos
BDD Testing checks software against behavioral examples agreed before implementation. It sits inside the Behavior Driven Development process: business, development, and testing participants clarify a rule, choose representative examples, then connect them to executable checks. A check may run at component, API, integration, or user-interface level. The current ISTQB Foundation syllabus groups BDD with test-first development approaches in which tests precede production code (ISTQB, 2024). A passing check confirms the agreed example under its stated conditions. It cannot prove complete coverage.
TL;DR: BDD Testing turns jointly clarified examples into executable checks. A sound method has 7 steps, from a small planned change to maintained automation. Run each check at the smallest practical test level. Keep a small set of UI checks for critical flows, then place most rule checks closer to the code.
Figure 1: Six stages from a business example to the test report.
What is BDD Testing?
BDD Testing is the testing practice built around concrete behavioral examples agreed by business, development, and testing participants before implementation. Each example states a context, an event, and an observable outcome. Cucumber splits the related work into 3 practices: Discovery, Formulation, and Automation (Cucumber, 2026).
Discovery identifies rules and unanswered questions. Formulation records selected examples in a readable structured form. Automation connects those examples to the system and produces repeatable results. Tooling enters during the third practice. A scenario written after implementation may still be a useful regression check. Cucumber does not classify that sequence alone as BDD (Cucumber, 2026).
“We call these practices Discovery, Formulation, and Automation.” The current Cucumber documentation uses this sentence for its three-part BDD cycle (Cucumber, 2026).
BDD Testing is a practice rather than a named framework. Gherkin is a common notation, and Cucumber is one possible execution tool. A team can implement the same examples with other test libraries, provided the rule, example, and observable result remain connected.
How does an example become an executable BDD test?
An executable BDD test emerges through 7 steps that connect conversation, formulation, and a technical check. The sequence starts shortly before development of a small change. Cucumber suggests 3 to 6 participants and 25 to 30 minutes per story as workshop rules of thumb, rather than fixed limits (Cucumber, 2026).
Select one small user story or a tightly bounded change planned for the next development period.
Bring product or business, development, and testing perspectives into one conversation.
Gather rules, positive and negative examples, plus unanswered questions.
Choose a small set of examples that explains each rule or exposes a boundary.
Write one context, one event, and observable outcomes for each scenario.
Select the smallest test level that can prove the behavior with dependable evidence.
Implement and run the check before its production behavior, then maintain specification and test code together.
Example Mapping gives the conversation a concrete structure: story, rules, examples, and questions use separate cards. A session ends once scope is clear or the agreed time expires (Cucumber, 2026). A broad example gets split. An unresolved rule remains visible as a question and does not disappear inside test code.
Which test level fits each behavior?
Figure 2: Many component checks and few UI system checks.
The right test level is the smallest system boundary that exposes trustworthy evidence for the agreed behavior. The ISTQB test pyramid places many small, isolated, fast checks near its base. Slower tests with more system scope sit higher and should be fewer in number (ISTQB, 2024).
Test level | Good fit | Main strength | Main risk | Selection rule |
|---|---|---|---|---|
Component or domain | A business rule without infrastructure | Fast and isolated evidence | Business readers may gain little from low-level detail | Use a direct code test when no external effect is needed |
Service or API | Observable contract across an interface | Stable execution and focused diagnosis | Test data can hide integration assumptions | Prefer this level before a UI check |
Integration | Behavior depends on real component interaction | Finds protocol and configuration faults | More dependencies complicate diagnosis | Limit each scenario to one rule and few systems |
UI system check | Critical user flow and deployed wiring | Visible effect across the running system | Slow execution and broad failure causes | Keep a small set of central flows |
Exploratory or manual | New risks, usability, and open questions | Finds problems outside known examples | Results are less repeatable | Use beside the agreed executable examples |
A pricing limit can often be proved at component or API level. A complete payment transaction may need an integration check. The interface is appropriate when presentation, navigation, or deployed wiring belongs to the behavior. The test pyramid gives teams a selection model, and API test automation explains common interface checks.
What makes a scenario testable and readable?
Figure 3: Given, When and Then separate context, event and result.
A testable scenario describes one business rule through context, one triggering event, and an observable outcome. Gherkin uses Given, When, and Then for that structure. Cucumber recommends 3 to 5 steps per example. The number is readability guidance, not a syntax limit (Cucumber, 2026).
Consider a daily transfer limit. The account has CHF 1,000 left. The customer transfers CHF 250. The remaining limit becomes CHF 750. The text contains no CSS selectors, screen coordinates, or database fields. Those details belong inside the automation layer.
The Cucumber reference expects Then to inspect an outcome visible to a user or external system. It says: “Then steps should use an assertion to compare the actual outcome to the expected outcome” (Cucumber, 2026). A scenario containing several rules, events, and outcomes loses diagnostic precision.
Readable scenarios tend to share these traits:
one named business purpose;
a clear starting context;
one central event;
at least one observable outcome;
consistent domain terms;
no technical interaction details.
What does a failed BDD scenario prove?
A failed BDD scenario proves that observed behavior differs from the executable specification. It does not locate the cause. One study mapped 166 BDD publications and found few metrics for specifications and their creation processes (Journal of Systems and Software, 2023). Logs and traces remain necessary.
A passing scenario has an equally precise boundary: the stated example succeeded with the used data and conditions. Other input classes, concurrency, security, performance, and unknown risks remain separate test objectives. Software testing fundamentals place such objectives inside a wider test strategy.
Which mistakes make BDD tests expensive?
BDD tests become expensive when business examples grow into technical scripts or lack clear ownership. Cucumber's current model contains 3 structured practices and puts joint work before automation. Its documentation rejects tool usage as proof of BDD practice (Cucumber, 2026).
Scenarios are written after production code is complete.
One tester owns Discovery and formulation alone.
Cucumber is treated as a substitute for business discussion.
UI selectors and click sequences appear in scenario text.
A long flow covers several rules and outcomes.
Every example runs through the user interface.
Scenarios share mutable state or unclear test data.
AI drafts enter the suite without domain review.
Can AI draft BDD scenarios, and where does Autemos fit?
Figure 4: AI drafts require context, domain review and approval.
AI can draft BDD scenarios, yet domain review and sufficient context remain necessary. A peer-reviewed study evaluated GPT-3.5, GPT-4, Llama-2-13B, and PaLM-2 with zero-shot and few-shot prompts. Its positive findings apply to that evaluation and do not establish universal reliability (IEEE Access, 2024).
A 2026 preprint examined 500 stories from 4 private software products. Inputs containing a user story plus a fuller description received higher ratings across 3 models than story-only input. The study has not passed peer review and is unsuitable as an industry result (arXiv, 2026).
According to its current product page, Autemos can turn an agreed Jira ticket, user story, or natural-language test description into a visual executable workflow. People review generated steps before execution (Autemos, 2026). Teams can connect existing Playwright checks to visual test workflows. Public material makes no claim of `.feature` import or Cucumber execution.
Use this sequence for reviewed automation:
The team clarifies behavior, rules, and representative examples.
Business owners confirm scope and expected outcomes.
Autemos creates a reviewable workflow from the approved description.
A person checks steps, data, system access, and expected results.
Execution returns diagnostic evidence for the agreed example.
Frequently asked questions
The 5 common questions concern definition, test level, automation scope, failure meaning, and AI assistance. Cucumber recommends 3 to 5 steps per example, treating that range as readability guidance instead of a syntax rule (Cucumber, 2026). The answers below keep process, scenario, and tool distinct.
What is BDD Testing?
BDD Testing checks software against concrete behavioral examples agreed before implementation. It connects Discovery, structured formulation, and executable checks. Cucumber names these three practices Discovery, Formulation, and Automation (Cucumber, 2026).
At which test level should BDD scenarios run?
BDD scenarios should run at the smallest test level that proves the behavior reliably. Component and API checks often return faster, clearer evidence. UI system checks are reserved for a small set of critical user flows and deployed system wiring.
Must every BDD test be automated?
The full test-first BDD cycle automates the selected example before its production behavior. Discovery examples can clarify open questions before any tooling enters. If automation has no stable value, the team should reconsider scope and test purpose rather than execute every example mechanically.
What does a failed BDD scenario mean?
A failed scenario shows a mismatch between observed behavior and the executable specification. Product code, data, environment, automation code, or specification may be responsible. Suitable logs and reports are required for diagnosis.
Can AI write BDD scenarios automatically?
AI can produce a first draft. Current studies report useful results in bounded evaluations and strong dependence on input quality. Domain review remains necessary since fluent text may still contain incorrect rules or omit boundary cases.
Conclusion
BDD Testing connects one agreed behavior to diagnostic evidence. The method described here has 7 steps, from a small planned change to joint maintenance. Cucumber groups the related work into 3 practices: Discovery, Formulation, and Automation (Cucumber, 2026). Test level remains a conscious architecture decision.
Clarify rules and boundary cases with the 3 required perspectives, then implement each example at the smallest useful test level. Keep a few UI system checks for central user flows. A failure report begins diagnosis; it does not complete root-cause analysis. AI can prepare drafts, with business owners retaining content approval. Autemos can turn approved descriptions into visual workflows and connect existing Playwright checks. To assess your current test architecture and available artifacts, talk with the Autemos team.
