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, a situation, a trigger, 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
A structured syntax for describing software behaviour, centred on Given-When-Then clauses. Designed to map directly to automated test steps.
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.
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a living product specification.
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.