Behavior-Driven Development (BDD) is a software development approach that focuses on collaboration between developers, testers, and non-technical stakeholders such as Business Analysts and Product Owners.
When a Business Analyst comes up with a new requirement for the application, the requirement is explained clearly in the Software Requirements Specification (SRS) documentation. However, developers might misinterpret these specifications.
For example,
SRS States: When a student is absent, the parent will receive a notification to submit the reason for absence, and the parent have to submit the reason within n number of days. After submitting the reason, it will be displayed in the Absence Reason Review page for teacher review, and the number of days can be configured in the Settings page.
Developer interprets: When a student is absent, the parent will receive a notification to submit the reason, and the parent have to submit the reason within n days. After submitting the reason, the reason will be displayed in the Absence Reason Review page for teacher review, but only for n days (after that, it disappears).
The developer thought the "n" days applied for how long the reason displays in the Absence Reason Review page, and the parent's time to submit the reason
BA actually intended: When a student is absent, the parent will receive a notification and must submit the reason within 7 days (this number is configurable in the Settings page).
If the parent submits the reason within 7 days, the reason stays in the Absence Reason Review page until the teacher reviews and approves it.
Result: The feature is built incorrectly, causing rework.
To avoid such misunderstandings, BDD was introduced.
BDD is a user-centric approach where requirements are written as behaviors based on user needs. These behaviors later become scenarios for automation testing.
In BDD, scenarios are written using the Given–When–Then format.
Scenario: Parent submits reason for student absence within the allowed time
Given a student is marked absent
And the parent receives a notification to submit a reason
When the parent submits the reason within 7 days
Then the submitted reason should appear in the Absence Reason Review page for teacher review
Scenario: Parent submits reason after allowed time
Given a student is marked absent
And the parent receives a notification to submit a reason
When the parent submits the reason after 7 days
Then the reason should not appear in the Absence Reason Review page for teacher review
This format makes the requirement easier to understand for all stakeholders. The language used here is called Gherkin syntax.
Using the Cucumber framework, we can write and automate test scenarios using this syntax.
In the next tutorial, we’ll explore the Gherkin language and its structure in more detail and learn how to write scenarios in Gherkin.