Behaviour-Driven Development
A software development practice where behaviour is described in a structured format (typically Gherkin) that can be read by stakeholders and executed as automated tests.
Behaviour-Driven Development (BDD) is a methodology that came out of Test-Driven Development in the mid-2000s. The core idea: describe product behaviour in a format that's precise enough to drive automated tests, but readable enough for non-engineers to review and approve. The most common syntax is Gherkin, Given-When-Then, and the most common tool is Cucumber.
In theory, BDD gives you a single artefact that's both a spec and a test suite. In practice, BDD tends to be owned and maintained by engineers, and the “readable by non-engineers” part rarely survives first contact with a real test suite. Most PMs find Gherkin uncomfortable to read. Most customer success managers have never encountered it.
Context/Action/Outcome borrows BDD's structural insight, three clauses for a situation, a trigger and a result, without the test runner baggage. No syntax to learn, no pipeline integration required, no assumption that the reader knows what BDD is.
Related terms
- INDUSTRY
Gherkin
A structured syntax for describing software behaviour, centred on Given-When-Then clauses. Designed to map directly to automated test steps.
- SPEC
Context, Action, Outcome
A structured format for describing product behaviour. Precise enough to be unambiguous, plain enough for anyone on the team to read, without the machine-oriented syntax of BDD.
- SPEC
Scenario
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a Specsight spec.