Behavior Driven Development(BDD) is an extremely powerful way for teams to elaborate user stories, providing teams with a deep contextual understanding of the features that they are building.  BDD is a technique that when mastered raises quality, improves productivity and provides the foundation for building high levels of test automation.

BDD was created by Dan North who found that there was a need to better communicate with our business customers who don’t speak in our language nor we in theirs.  This chasm of language creates many issues with respect to identifying how something being developed should behave.

If you query BDD on the web you will undoubtedly receive a long list of sites telling you all about the automation side of BDD.  Yes, automation is the foundation for teams to go fast but it is not the core reason for developing BDD acceptance test writing capabilities.  Automation is icing on the cake.

There is very little information available online that actually tells you how to write good BDD.  From experience, I can tell you that it takes some time to get comfortable with the format and that we learn by doing.  Having help from someone who has done it before makes the process much easier for sure. 

As someone who’s been actively using BDD for more than ten years, it has become a central part of how I work and how I coach teams to write great user stories.  I’ve seen the value it produces for such organizations as Disney, PayPal, NCR and Opower and each organization that has leveraged BDD as part of their story development efforts have seen improvements in quality, productivity and test automation.

BDD provides the foundation for us to go fast and adhere to a zero defect policy sprint to sprint.  Adding automation to the mix increases the value many times over as you are continually building your automated regression suite, something I call progressive regression. 

In order to be successful with BDD we need to treat it as a team event, it’s not a QA, Dev or even just a PO thing, everyone needs to participate to ensure that we have the necessary behavior identified for our feature stories.  Most defects that we find are typically either misunderstood or misinterpreted requirements.  BDD removes the vagueness that we often see with requirements and gets both the Developers and Testers with a shared understanding.  If we miss something it’s a shared miss, no finger-pointing, simply write a new story and add it to the backlog.

Too often you see BDD written with the standard Given/When/Then but no parameters with which to build out the Example table.  If you find that you are writing all of your BDD and aren’t getting example tables you are either not understanding the story or the story is so small that there is only one outcome or behavior identified. 

That’s the thing, in order for you to have success with BDD you have to be able to generate Example tables, these are the key to creating a contextually rich understanding of the behavior of the story.  Having your team work together in building out the example table ensures that we are all focused on delivering the same thing.  If we miss something it's a shared miss, write a new story,put it in the backlog and prioritize it with the rest of the work.

If you would like to learn more about the basics of BDD you can listen to my BDD Introduction. Here you will begin to learn the semantics and thinking that goes into writing effective BDD.

However, if you prefer we can work with you 1:1 on specific stories that you are working on so that you can deliver value to your organization with BDD.