This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.
- Part 1: Introduction
- Part 2: Narrative
- Part 3: Scenarios
- Part 4: Automation
The previous post explained narrative as a format to describe feature or requirement. Even though narratives can be written by anyone, it is often the result of conversations between the product owner or the business analyst and business stakeholder.
Scenarios describe interactions between user roles and the system. They are written in plain language with minimal technical details so that all stakeholders (customer, developers, testers, designers, marketing managers, etc) can have a common base for use in discussions, development, and testing.
Scenarios are the acceptance criteria of the narrative. They represent the definition of done. Once all scenarios have been implemented, the story is considered finished. Scenarios can be written by anyone, with testers leading the effort.
The whole process should be iterative within the sprint; as the development of the BDD story progresses, new scenarios can be written to cover cases not thought of before. The initial set of scenarios should cover the “happy path”. Alternative paths should be added progressively during the duration of the sprint.