What is BDD?
I often hear of teams saying they practice ‘BDD’ and prove it to me by waving Given When Thens in my face, let’s check the definition of what BDD actually is:
Behavior Driven Development is a process designed to aid the management and the delivery of software development projects by improving communication between engineers and business professionals
I ask them how many “Business Professionals” have even seen their feature files, 9 times out of 10 the answer is “none”. Too often the testing/QA team use feature files as a shield in front of the automated test code lurking beneath and no other real benefit. Another misuse is hiding them away in stories during refinement and no one ever looking at them again, including the developers.
What’s the fix?
Take a step back, think, why are we writing these? Do you actually get real benefit from it? Are your steps just lists of actions that remind you of test cases of yesteryear?
Write the scenarios early in the development cycle, but most importantly collaborate on them. Make sure it’s not just a test effort.
When you are writing your scenarios, keep them at a ‘Behavior’ level – don’t dive into the specifics. Diving into the specifics can spark a lot of debate which is probably not relevant this early in development cycle. Don’t list out step after step of application specific detail.
Take a look at this example of good and bad gherkin for example:
The Bottom Line
If you aren’t writing your scenarios early in the cycle or making them visible, you’re missing out on the benefits of doing BDD. Removing communication gaps is the main idea behind BDD, and from a testing perspective that reduces defects caused from misunderstandings. If you aren’t writing them early enough, you’ll be too late to the conversation. If you aren’t making them visible then you aren’t part of the conversation. As we all know, it is cheaper and less painful to prevent defects if we can.
Remember, Gherkin is just one example of specifying behavior, there are many others!