Download - Acceptance Testing in BDD
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