The BDD Approach

User Stories provide overall expectations

Scenarios break down the stories into granular happy/unhappy paths

Scenarios are specified using natural language (Gherkin)

These scenarios can be executed as code (i.e. the scenarios are the automated tests)

BDD processWriting scenarios creates failing tests, as code has not been written yet. The scenarios

give the developer clear direction i.e. making the test (scenario) pass.A story is only considered complete once the scenarios pass

Main advantages

Because automated tests are directly correlated to user story scenarios, they are accurate

Developers have clearer, more specific direction

Scenario Gherkin lines can most likely be re-used, hence development of reusable domain-specific language.

Where's the test plan?

Test plans existed to bridge gap between project management and QA (i.e. defining test scope and schedule).

The testing function can exist separate to development, but BDD effectively bridges the gap.

BDD test creation are driven by User stories, the definition of “Done”, and project schedule.

Reports are generated with each test run, providing audit trail

QA strategy details testing types, tools and sign-off criteria

Where's the test plan?

Test plans existed to bridge gap between project management and QA (i.e. defining test scope and schedule).

The testing function can exist separate to development, but BDD effectively bridges the gap.

BDD test creation are driven by User stories, the definition of “Done”, and project schedule.

Reports are generated with each test run, providing audit trail

QA strategy details testing types, tools and sign-off criteria