The SQA2 Blog: Advice Center
BDD
Over the years Behavior Driven Development (BDD) has been increasing in popularity with many companies. However, just because something is popular doesn’t mean it’s the right fit for everyone. I myself have worked at many different companies that utilized BDD, but like everything, they were used very differently. Over the course of this blog I want to address the common mistakes many first time users fall into when it comes to structure, process and re-usability.
It is about the Behavior
As the name suggests, BDD focuses on the Behavior of a particular feature. You would think that it’s easy to remember, it’s in the name right? But many times people fall into the trap of creating new feature files for every ticket or story scheduled. This, in the end, becomes a management nightmare. For example, if your team completes about 15 stories in a two week sprint (Agile methodology), that’s about 360 stories a year for one team, which includes a total of 360 feature files. The issue with this approach is that many stories will focus on the same feature, with slight modifications, or maybe the story was just cleverly broken down into tiny achievable stories. For this very reason, its best for all that are involved to make additions to existing feature files versus just creating new ones.
Teamwork is key
Every team doesn’t always adopt all the best practices when it comes to the framework. The majority see the popularity and just want it used, but never take into account all that’s involved. In many cases it’s just used by developers. Although there is nothing wrong with this, the best approach I’ve experienced is when product owners, QA engineers, and developers work together.
The best practices themselves call for teamwork. When the product owner creates their stories they should include BDD like acceptance criteria for the developers to work on. This allows the developer(s) to write “failing” BDD tests, which should pass once the code has been implemented. This helps not only the developer(s) but product owners get exactly what they were asking for. In the midst of all this is QA, creating all additional BDD tests. This should all be reviewed by both product owners and developers, bringing the team closer together and getting everyone on the same page. Even with clear acceptance criteria, things can be assumed or expected.
Plain, free-form English
Depending on your team, even with the right foundation, BDD can be more difficult than other tools. A lot of difficulties a team can face come with being aware of all the steps already created. There is a discipline needed, to be actively involved with everything in the framework. BDD in some scenarios can be a keyword type of framework when done just right. Getting the team to be aware of those steps can be one of the biggest hurdles to get over, reuse as much as possible. BDD allows its users to write steps in plain, free-form English with just some minor formatting. But, I’ve seen too many times where people get hung up on the actual steps. Since every step requires a “Given, When, Then” sometimes it’s easy to fall into the trap of thinking that those annotations are part of the actual step.
Conclusion
So in conclusion BDD is a great tool, it might be difficult at times, and definitely isn’t for everyone, but if used correctly, can provide amazing coverage. With the knowledge of the common mistakes this should help avoid any headaches moving forward. For those that are just getting started, you should review my other blog BDD Patterns. It will help you understand feature files and step definition files in more detail.
