Behavioral Driven Development is a method of breaking down customer requirements into discrete, real-life scenarios at the feature level. Simply put it is a way to use plain customer activities and expectations, known as customer requirements, to craft the feature set for a product. These customer requirements are then used to create the User Story and build in the scenario into the test plan or acceptance criteria of that story.
BDD starts with customer requirements often relayed to the team’s product owner. Then the product owner and the team have a discussion where they elaborate on the requirements and eventually define them in a structured format.
The most common of these structured formats is known as the Gherkin format that follows the prompts Given, When, Then.
Here is a simple example of BDD:
“I want to be able to login to the website and see my account summary screen.”
Customer Requirement in Gherkin Format:
Given: that I am on the login screen
When: I attempt to login with valid credentials
Then: I am taken to my account summary screen
What’s the value?
This simplifies the testing because the customer requirement becomes the basis for the test script for the associated User Story. BDD also engages testing earlier in the process at the creation of the user story aligning development and testing directly with the customer requirement. The customer focus of BDD is the real heart of the value proposition. The customer scenario being written in plain language allows each team member to understand what the customer wants, why they want it, and any pain points along the way.
And… now you understand BDD!
Join our Pro Tips Pipeline
4 thoughts on “What is BDD?”
BDD is really helpful because it helps the organization truly understand what the customer wants. I have done projects for my own company where I started delivering a LOT more than the customer actually required. Now I spend the time to figure out what the customer wants.
Exactly! Why spend time building what you THINK the customer wants when you can build their feedback into the development process to ensure you deliver what they want.
BDD (thinking of it through the Gherkin format) seems like it can be very beneficial to the team members because of the simple thought process of how to clearly understand the customer’s needs. (The starting point or information the customer has provided……..the action step the customer takes…… then the result the customer wishes to be delivered) Am I following/understanding it correctly?
I love the directness of it. Doesn’t leave room for confusion