We observe usually, product owners deliver their requirements to the developers as a first step during a development cycle, preferably before QA. As the development cycle begins, developers, product owners, stakeholders have a continuous communication, taking reference of the user stories and acceptance criterias. During the development process, product managers and stakeholders track the development progresses but sometimes technical side comes meaningless for them. At this point, a common language is needed like a bridge to connect stakeholders and technical teams. Behaviour Driven Development is a development approach which fills the information gap between stakeholders and development teams.
BDD ensures everyone (technical or not) has thorough visibility into the project’s progress.
On the other hand the nature of BDD can make separate requirement analyses (acceptance criterias) absolute, favoring product owners, business analysts and developers to work on same reference analyses source.
Optionally, business analyst can make ‘git commit’ on those source files.
Behaviour Driven Development is an extension of test-driven development
As developers target is to make pre-developed unit tests passes in TDD approach, similarly in BDD, developers target is to make behaviour-driven tests passes which are pre-developed usually by QAs .
Behaviour Driven Development uses examplesto illustrate behaviour
Scenario: Refund A Toy and Verify Refund Amount
Given a customer has purchased a toy
And the toy cost 25$
When the customer refund the toy
Then the customer should be refunded 25$
In principle, aim is the answer the questions “WHO”, “WHAT”, “WHY”:
Describe the behaviour of your software in a very understandable way!
Given a context
When an event happens
Then an outcome should occur
Feature: Login functionality check
As a customer manager
I want to test login feature
To verify whether customers can log in or not to the web application
Scenario: Login with invalid email and valid password
Given visit homepage
When fill "Email" with "email@example.com"
And fill "Password" with "1313rpe2"
And click "Login" button
Then page should contain "Wrong email or password" content
As a result, considering the experimental approach in DevOps, BDD is worth the try by not ignoring the continuous improvement cycle, evolving it towards your internal dynamics.