Behavior-Driven Development
Also known as: BDD
Behavior-Driven Development (BDD) is a collaborative approach where features are described as Given/When/Then scenarios in plain language before any code is written, so developers, testers, and product stakeholders share one unambiguous definition of "done." Those scenarios, typically written in Gherkin, often become the automated acceptance tests themselves.
BDD grew out of test-driven development, but shifts the question from "does this code work" to "does this code do what the business actually wants." A scenario is written collaboratively — often in a "three amigos" session with a developer, a tester, and a product owner in the room — before implementation starts, which surfaces disagreements about requirements while they're still cheap to resolve.
The Given/When/Then structure forces precision: Given describes the starting state, When describes the action, Then describes the observable outcome. Tools like Cucumber and SpecFlow parse Gherkin-written scenarios and map each line to automated step-definition code, so the same plain-English scenario a product owner reviewed is the exact thing running in CI.
BDD isn't really a testing technique on its own — it's a shared-language technique that happens to produce testable, automatable specifications as a side effect. Teams that adopt the Gherkin syntax without the collaborative writing process tend to get the ceremony without the actual benefit.
Example
Scenario: Successful login with valid credentials
Given a registered user is on the login page
When they enter a valid email and password
Then they are redirected to the dashboardA Gherkin scenario — readable by a product owner, executable by Cucumber.
