BDD is a collaborative software development approach where the expected behavior of a feature is described in plain, business-readable language (usually Gherkin) BEFORE implementation, so business, developers, and testers share one understanding.
BDD extends Test-Driven Development by focusing on behavior from the user's perspective and expressing it in natural language everyone can read. Requirements become concrete examples (scenarios) written in Given/When/Then form, which double as living documentation and automated acceptance tests. The goal is to close the gap between what the business wants and what gets built, reducing miscommunication. BDD is a process/mindset; Cucumber, SpecFlow, and Behave are TOOLS that automate BDD scenarios. The value is collaboration and shared understanding — not just the automation.
Before building a discount feature, the team writes scenarios like 'Given a cart over $100, When checkout, Then a 10% discount applies' — agreed by product, dev, and QA, then automated so the spec verifies itself.
In an interview: 'Is BDD just another testing framework?' How do you answer?