Behavior Driven Development is a collaborative development process that clarifies desired software behavior through concrete examples before implementation. Business, development, and testing perspectives discuss rules, edge cases, and observable results before code is written. Cucumber’s 2026 documentation names three recurring practices: Discovery, Formulation, and Automation (Cucumber, 2026). BDD Testing turns the agreed examples into executable specifications. Gherkin and Cucumber can support this work, but they do not define BDD. This guide covers the process, roles, test levels, research evidence, and a limited pilot based on one product story.

TL;DR: BDD connects business, development, and testing perspectives through concrete examples before implementation. Discovery clarifies rules, Formulation records selected examples, and Automation checks them through executable tests. A study classified 166 BDD papers, yet found scarce industry evidence and few measurement methods (Binamungu and Maro, 2023).

Figure 1: Discovery, Formulation, and Automation form a BDD work loop with feedback.

What is Behavior Driven Development?

Behavior Driven Development is a collaborative software development process based on examples of observable behavior. Its current operating model contains 3 practices: Discovery, Formulation, and Automation (Cucumber, 2026). BDD joins requirements discussion, readable specification, and test-first implementation in short cycles around small changes.

Participants discuss an upcoming change. They identify concrete situations, expected results, and unresolved questions. Selected examples later become executable checks. The process begins before programming and stays testable during implementation.

Dan North developed the term through his work teaching Test Driven Development. He began JBehave near the end of 2003 and published his BDD description in 2006 (Dan North, 2006). Agile Alliance describes BDD as a synthesis and refinement of TDD and ATDD practices (Agile Alliance, 2015). Our BDD versus TDD comparison explains their separate working levels.

BDD is a process. BDD Testing is the testing practice around agreed examples. Gherkin is a structured plain-text notation. Cucumber reads Gherkin and connects steps to programming code. Each term answers a separate question:

Agile Alliance describes BDD as independent of any required tool or programming language (Agile Alliance, 2015). A team may record examples on cards, in tables, or directly in test code. Collaborative work before implementation remains the defining condition.

Which problem does BDD address?

Figure 2: Business, development, and testing clarify one concrete example together.

BDD exposes ambiguity before it enters code and automated tests. A systematic study classified 166 publications from 2006 through 2021 and found scarce industry evaluation (Binamungu and Maro, 2023). The defensible benefit starts with structured clarification, rather than a guaranteed delivery or defect result.

User stories often state an aim and leave business rules open. “Customers can cancel an order” says nothing about deadlines, partial orders, payment status, or refunds. Developers and testers may read the same words in different ways. Such differences can first appear during acceptance, after several technical decisions already depend on them.

Concrete examples require testable statements. An example names an initial state, an event, and a visible result. Participants see missing rules and conflicting assumptions earlier. Open questions remain explicit, rather than entering implementation as silent guesses.

BDD cannot make a product decision. A workshop may reveal that the cancellation deadline has no owner-approved value. A product decision must supply that value. Risk, privacy, performance, accessibility, and exploratory testing need separate decisions too. The BDD Testing guide places agreed examples inside a broader test strategy.

How do Discovery, Formulation, and Automation work?

Discovery, Formulation, and Automation form a recurring 3-practice loop around small changes (Cucumber, 2026). Discovery identifies rules and examples, Formulation records selected cases in readable form, and Automation connects each case to an executable check. New findings return to a later Discovery conversation.

A single business rule moves through the process in this sequence:

1. A product representative describes one small upcoming change.

2. The three perspectives collect positive, negative, and boundary examples.

3. The group selects cases that explain each rule most clearly.

4. It records each case with context, one event, and an observable result.

5. Development connects the first case to an executable check.

6. The check fails before implementation, then the team writes the required behavior.

7. The passing check stays with the specification and runs again after changes.

Cucumber gives the practices a compact name: “We call these practices Discovery, Formulation, and Automation” (Cucumber, 2026). Their sequence separates BDD from test automation written after implementation. A Given-When-Then scenario added after production code may be a sound regression test. Cucumber’s current guidance classifies that sequence outside BDD (Cucumber Myths, 2026).

Formulation may use Gherkin syntax. Keywords alone cannot create readability. A useful scenario explains one business rule, excludes technical selectors, and names a result visible to a user or external system.

Who takes part in a Three Amigos session?

A Three Amigos session needs at least 3 perspectives: business or product, development, and testing (Cucumber, 2026). The name does not impose an attendee limit. Cucumber gives 3 to 6 people as a practitioner rule and 25 to 30 minutes as a guide per story (Cucumber, 2026).

The product perspective explains the outcome, scope, and domain rules. Development identifies dependencies, data states, and implementation constraints. Testing asks about negative paths, boundaries, and observable results. Legal, operations, security, or data specialists can join when the story depends on their decisions.

Example Mapping gives the discussion a simple structure. Cucumber uses a yellow card for the story, blue cards for rules, green cards for examples, and red cards for open questions (Cucumber, 2026).

An order-cancellation story could contain:

• Story: A customer can cancel a paid order.

• Rule: Cancellation is available before dispatch.

• Example: A paid, undispatched order produces a refund.

• Counterexample: A dispatched order produces a clear rejection.

• Open question: Do digital products follow a different deadline?

A large map indicates excessive story scope. Open red cards preserve unresolved decisions. The session ends with clear scope or a named decision owner.

How can a team introduce BDD with one story?

Figure 3: Example Mapping organizes a story, rules, examples, and open questions.

A limited pilot based on 1 small upcoming story gives a team a controlled introduction. Cucumber recommends Discovery late enough to retain context and before implementation begins; it gives 25 to 30 minutes as a practitioner guide (Cucumber, 2026). The pilot tests the working method without requiring company-wide change.

1. Choose the story: Select a meaningful change with narrow scope and an observable result.

2. Invite the perspectives: Product, development, and testing must be represented. Add specialists for defined decisions.

3. List the rules: Record each domain rule separately. Mark unclear terms immediately.

4. Test the examples: Add normal cases, boundaries, rejection paths, and missing data.

5. Keep open questions: Name the decision owner and avoid guessed answers.

6. Write focused scenarios: Select a small set of examples and state visible outcomes.

7. Choose the test level: Place each check at the smallest practical level that proves its behavior.

8. Run before coding: Observe the first failure, write the production behavior, and run the check again.

9. Review the work: Examine readability, diagnosis time, and maintenance after the story is complete.

The pilot needs explicit observation criteria. Count domain questions settled before coding, scenarios rewritten during implementation, and time required to explain a failed check. These local values do not establish a universal BDD effect. Repeat the process across several risk types before setting a wider policy.

What do Gherkin and Cucumber do?

Gherkin is a structured plain-text notation with more than 70 language versions; Cucumber is a tool that parses these texts and binds them to code through Step Definitions (Cucumber Gherkin Reference, 2026). Both can support BDD. The process remains independent of any required notation or programming language.

Gherkin structures a specification with keywords such as Feature, Rule, Scenario, Given, When, and Then. Given describes the initial context. When states an event or action. Then states an outcome visible to a user or external system. Cucumber recommends 3 to 5 steps per example as a readability guide, not a syntax limit (Cucumber Gherkin Reference, 2026).

Cucumber reads each scenario and finds matching Step Definitions. Those functions perform the technical work, such as calling an API or operating a browser. The tool reports success or failure for each scenario. The Cucumber testing guide covers project structure, Step Definitions, and maintenance in more detail.

A `.feature` file proves that structured text exists. Current Cucumber guidance requires Discovery before Formulation and Automation for a BDD process (Cucumber Myths, 2026). Teams need separate evidence that domain representatives took part, examples preceded code, and scenarios remain readable.

Which test levels fit BDD examples?

BDD examples can run at component, service, integration, or UI level. The 2024 ISTQB syllabus describes a test pyramid with many small and fast checks at its base and fewer slow system checks at its top (ISTQB, 2024). The selected level should prove behavior with little unnecessary system scope.

A discount rule usually belongs in direct domain tests. A pricing query between services belongs at API or integration level. A critical checkout needs a small number of UI system checks. This distribution follows the test pyramid and reduces broad duplicate checks.

BDD does not supply the whole test strategy. Security testing, load testing, accessibility, and exploratory work need their own objectives. An executable specification covers agreed behavior. Unknown risks remain part of wider testing. Distributed systems may need the separate API test automation guide.

What does current research show, and where are its limits?

Figure 4: The 166 mapped BDD papers contrast with scarce industry evidence and few measures.

The strongest research overview classified 166 BDD papers published from 2006 through 2021 and reported scarce industry evidence plus few measurement methods (Binamungu and Maro, 2023). BDD has a broad research record, but no defensible universal percentage for fewer defects, delivery time, or return on investment.

“The study identified 166 papers which were mapped.” (Binamungu and Maro, 2023)

The 2025 case study observed 4 teams with 56 participants across 6 sprints. Its reported final percentages came from 4 team leaders; 50 percent said objectives were met and 50 percent said they were partly met (Ribeiro dos Santos et al., 2025). Four responses cannot establish a broad effect size.

A peer-reviewed 2024 IEEE study tested GPT-3.5, GPT-4, Llama-2-13B, and PaLM-2 for BDD acceptance-test generation. Its findings apply to its stated criteria and inputs (Karpurapu et al., 2024). A 2026 preprint examined 500 stories from 4 proprietary products and found higher ratings from a story plus description. Quality varied, and text-similarity measures mostly correlated below 0.30 with human judgments (Shahin et al., 2026). Domain review remains necessary.

Where can Autemos support the Automation practice?

Autemos can turn agreed descriptions into executable test workflows after Discovery and Formulation. Its product page names 3 input forms: a Jira ticket, a user story, or a natural-language description (Autemos, 2026). The domain team retains ownership of rules and acceptance, with human review before execution.

A BDD team can use an agreed story or test description as input. Autemos produces visual workflows, Page Objects, and executable code for team review. Existing Playwright, Selenium, and Appium codebases can be reused according to the product page (Autemos, 2026). Visual test workflows give domain contributors and engineers different views of the same executable flow.

Public documentation makes no claim of native Cucumber execution, Gherkin import, or `.feature` import. This boundary matters for architecture decisions. An existing Cucumber project needs an explicitly tested integration design. Autemos can support Automation, but it cannot conduct Discovery or approve a domain outcome.

A narrow evaluation should use these controls:

• Start from one agreed story with a small set of examples.

• Review generated steps for domain and technical accuracy before execution.

• Choose a test level for each behavior explicitly.

• Measure diagnosis time, revision work, and maintenance in the local team.

• Record boundaries between the BDD specification and execution platform.

Frequently asked questions

Common BDD questions concern definitions, tools, and roles. Current Cucumber documentation divides the process into 3 practices and requires at least 3 represented perspectives (Cucumber, 2026). The following answers keep the process, notation, execution tool, and research evidence separate.

What is Behavior Driven Development?

Behavior Driven Development is a collaborative development process where business, development, and testing perspectives clarify desired behavior through examples before implementation. Selected examples are written in readable form and checked through executable tests. Discovery, Formulation, and Automation make up the recurring work cycle (Cucumber, 2026).

Is BDD the same as Cucumber?

BDD and Cucumber belong to separate categories. BDD is the development process; Cucumber is an open-source tool that parses structured specifications, runs Step Definitions, and reports each scenario’s result (Cucumber, 2026). Teams can practice BDD without Cucumber.

Does BDD require Gherkin and Given-When-Then?

BDD requires no fixed notation or programming language (Agile Alliance, 2015). Gherkin with Given, When, and Then is common since it separates context, event, and observable result. Cards, tables, or other clear formats can fulfil the same Formulation purpose.

Who joins a Three Amigos session?

Business or product, development, and testing must be represented as 3 perspectives. Cucumber sets no maximum of 3 people and gives 3 to 6 participants as a practitioner rule (Cucumber, 2026). Extra specialists join for relevant domain decisions.

Which BDD benefits have scientific evidence?

Research records many BDD applications, but it supports no universal effect percentage. A mapping of 166 papers found scarce industry evaluation and a shortage of measures for BDD specifications and processes (Binamungu and Maro, 2023). Teams need their own objectives and measures.

Conclusion

Behavior Driven Development starts with one small change and concrete examples before code. Its current process description contains 3 practices: Discovery, Formulation, and Automation (Cucumber, 2026). Business, development, and testing perspectives clarify rules, write a few focused scenarios, and check them at a suitable test level. Gherkin and Cucumber are optional supporting choices.

Research covering 166 classified papers gives no universal BDD success percentage (Binamungu and Maro, 2023). A team should start with 1 story, collect local process measures, and record tool boundaries. That record makes local effects visible without turning guidance into a promise. To assess how Autemos turns agreed test descriptions into visual executable workflows, book a technical discussion.