What Is BDD? Behaviour-Driven Development Philosophy and Workflow

📚 QA Engineering 📂 Chapter 78: BDD with Cucumber and SpecFlow — Bridging Business and Automation 📄 Lesson 78010 Advanced 🕒 April 8, 2026

Behaviour-Driven Development is not a testing technique — it is a collaboration practice. BDD brings business stakeholders, developers, and testers together to define application behaviour in a shared language before any code is written. The output is a set of executable specifications — plain-English scenarios that describe what the system should do, which are then automated as tests. When done correctly, BDD produces living documentation that is always up to date because the documentation is the test suite.

The BDD Philosophy — Collaboration Before Automation

BDD is often misunderstood as “writing tests in Gherkin.” The real value is the conversation that produces the Gherkin — the Three Amigos session where business, dev, and QA align on what to build.

# The BDD workflow — Three Amigos to Living Documentation

BDD_WORKFLOW = [
    {
        "phase": "1. Discovery (Three Amigos Session)",
        "who": "Product Owner + Developer + Tester",
        "activity": "Discuss the user story; ask 'What should happen when...?' questions",
        "output": "Shared understanding of expected behaviour; concrete examples",
        "time": "30 minutes per user story",
    },
    {
        "phase": "2. Formulation (Write Scenarios)",
        "who": "Tester (with PO review)",
        "activity": "Convert examples into Gherkin scenarios (Given/When/Then)",
        "output": ".feature files — executable specifications in plain English",
        "time": "15 minutes per scenario",
    },
    {
        "phase": "3. Automation (Step Definitions)",
        "who": "SDET / Automation Engineer",
        "activity": "Bind Gherkin steps to automation code (Selenium, API calls)",
        "output": "Automated tests that run the scenarios against the application",
        "time": "30-60 minutes per scenario",
    },
    {
        "phase": "4. Living Documentation",
        "who": "Entire team",
        "activity": "Feature files serve as always-up-to-date documentation",
        "output": "Stakeholders read .feature files to understand system behaviour",
        "time": "Ongoing — updated as requirements change",
    },
]


# BDD vs traditional test automation
COMPARISON = {
    "Traditional Automation": {
        "specification": "Test cases in a test management tool (TestRail, Jira)",
        "documentation": "Separate from code; drifts out of date",
        "collaboration": "Tester writes tests after development; silos between roles",
        "language": "Technical — code that only testers understand",
        "example": "def test_login_valid(): driver.find_element(By.ID, 'user')...",
    },
    "BDD Automation": {
        "specification": "Feature files in version control alongside code",
        "documentation": "IS the test — always up to date because it runs",
        "collaboration": "Three Amigos discuss behaviour before development starts",
        "language": "Business language — anyone can read and review",
        "example": "Given I am on the login page\nWhen I enter valid credentials\nThen I should see the dashboard",
    },
}

# BDD tools by language
BDD_TOOLS = [
    {"language": "Python",     "tool": "Behave or pytest-bdd", "runner": "behave / pytest"},
    {"language": "JavaScript", "tool": "Cucumber.js",          "runner": "cucumber-js"},
    {"language": "Java",       "tool": "Cucumber-JVM",         "runner": "JUnit / TestNG"},
    {"language": "C# (.NET)",  "tool": "SpecFlow / Reqnroll",  "runner": "NUnit / xUnit"},
    {"language": "Ruby",       "tool": "Cucumber (original)",  "runner": "cucumber"},
]

print("BDD Workflow:")
for phase in BDD_WORKFLOW:
    print(f"\n  {phase['phase']}")
    print(f"    Who: {phase['who']}")
    print(f"    Activity: {phase['activity']}")
    print(f"    Output: {phase['output']}")

Note: The Three Amigos session is the most valuable part of BDD — not the Gherkin syntax, not the automation, not the tooling. When a product owner, developer, and tester sit together for 30 minutes to discuss “what should happen when a user enters an expired coupon?”, they surface edge cases, clarify ambiguities, and align on acceptance criteria before anyone writes code. This upfront alignment prevents defects caused by misunderstood requirements — the most expensive category of software defects because they are discovered late.

Tip: Start BDD with one team and one feature. Do not roll it out organisation-wide on day one. Choose a cross-functional team that is open to collaboration, pick a user story, and run a Three Amigos session. Write 3-5 Gherkin scenarios, automate them, and demonstrate the living documentation to stakeholders. Success with one team builds momentum for broader adoption; failure with ten teams simultaneously kills the initiative.

Warning: BDD without the collaboration phase is just “writing tests in Gherkin” — adding a translation layer between test code and Gherkin keywords without gaining any business alignment. If testers write Gherkin scenarios in isolation, developers never read them, and product owners never review them, you have all the maintenance cost of BDD (maintaining .feature files AND step definitions) with none of the collaboration benefit. BDD requires genuine cross-role participation to deliver value.

Common Mistakes

Mistake 1 — Adopting BDD as a testing technique instead of a collaboration practice

❌ Wrong: “We adopted BDD — our testers now write all tests in Gherkin instead of code.”

✅ Correct: “We adopted BDD — our product owners, developers, and testers discuss acceptance criteria together using concrete examples before development starts. The examples become Gherkin scenarios that are automated and serve as living documentation.”

Mistake 2 — Writing scenarios after development instead of before

❌ Wrong: Developer builds the feature, then tester writes Gherkin scenarios to retroactively document what was built.

✅ Correct: Three Amigos discuss and write scenarios before development. Developer uses scenarios as acceptance criteria. Tester automates the scenarios as development progresses.

🧠 Test Yourself

What is the most valuable outcome of a BDD Three Amigos session?

A complete set of automated test scripts ready to run in CI.
A shared understanding of expected behaviour across business, development, and QA — achieved through concrete examples that expose ambiguities, edge cases, and missing requirements before any code is written. This alignment prevents the most expensive category of defects: those caused by misunderstood requirements, which are typically discovered during testing or in production and require rework of both code and tests. The Gherkin scenarios are a byproduct of the conversation — valuable as documentation and automation input, but secondary to the alignment itself.
A Gherkin feature file that can be used as user documentation for end users.
A prioritised list of test cases ranked by business risk.

The BDD Philosophy — Collaboration Before Automation #

Common Mistakes #

Mistake 1 — Adopting BDD as a testing technique instead of a collaboration practice #

Mistake 2 — Writing scenarios after development instead of before #

🧠 Test Yourself #

📚 More in this Tutorial Series

The BDD Philosophy — Collaboration Before Automation

Common Mistakes

Mistake 1 — Adopting BDD as a testing technique instead of a collaboration practice

Mistake 2 — Writing scenarios after development instead of before

🧠 Test Yourself