Behavior Driven Development, or BDD, can help your teams build the right product. Although I’ve heard the term used interchangeably with Test Driven Development (TDD), I see it as an extension of TDD to help your team focus on the business’ goals. While TDD provides tests that drive development, those tests may or may not be helping you meet those goals.
BDD vs. TDD
Behavior-Driven Development | Test-Driven Development |
Start with business value, then drill down to feature sets | Lots of tests that may or may not meet the business value |
Team gets feedback from the Product Owner | Coder gets feedback from the code |
BDD is a more outside-in approach that is really focused on business drivers. It takes TDD a step further (as you still want that feedback from the code), but it now gives you feedback on the feature.
Getting Started with BDD
So what is the general process to use BDD? It aligns itself nicely in the Agile framework and is simply a WAY to implement Agile. Continue with your usual scrum activities: milestone planning, defining user stories and acceptance criteria and developing, and iteratively repeat that process until you are ready to release.
Epics and Milestone Planning – This is critical — It is the first step on your way to BDD. It helps you identify your overarching business goals and how you can deliver them.
Break your epic down into high-level milestones with the most basic slice of functionality, and flesh it out from there.
Not all milestones are released, but are releasable (similar to user stories).
Define Acceptance Criteria for each milestone (which turn into your user stories).
Estimates are refined ITERATIVELY as you continue to plan, deliver, and dive into spikes for technical investigation.
Ensure that your entire team (PM, Dev, QA, Design) are involved here. This allows for the entire team to have a clear vision, but especially for PM to see how the feature grows, and to identify dependencies quickly, helping facilitate prioritization across scrum teams. There is constant feedback before work even starts.
User stories / Behavior – Address the WHY and WHO over the HOW. Your typical format looks something like this (keep in mind syntax will be different framework to framework):
Format | As |
Example | As |
When do you define stories? You should do this as you iteratively go through your milestones and backlog grooming. The next step for each story is Acceptance Criteria.
Acceptance Criteria / Step Definition – Define the scenarios to meet your user story. In BDD, this is done in Given, When, and Then statements:
Format | Given |
Example | Given |
Example | Given |
It’s important to try to stay away from UI specifics like “When I Click this Button”, because the UI can change and then your step isn’t really applicable. We call this DECLARATIVE form.
When should this be done? During your backlog grooming! As with the user stories, this is an iterative process. The most critical thing is to not take a story into a sprint until the entire team agrees on the acceptance criteria! Many times, defining spawns further questions or acceptance criteria, and helps get deeper clarity to the feature. On my own teams, we go over each step driven from the scenarios to decide if it can be done via unit tests or if it needs to be done through the UI.
The Best Way to Implement BDD
BDD is tool agnostic. Of course there are great tools out there to help you automate this (Cucumber, JBehave, for example — read Greg Sypolt’s post about writing a good Cucumber test), but the main goal is to get your teams talking and to discover where you may need more clarification. The conversations are much more important than the tools.
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
