BDD (Behavior-Driven-Development) is a framework to integrate business’s expectations from the product to the development. Oftentimes, there’s disconnect between what the business expects, and what’s being developed. To avoid this, BDD provides a formal way of writing the behavioral expectations through examples, in the form of Feature Files, which can be used as test specifications for checking behaviors. A comprehensive write-up on BDD along with references can be found here. In this blog, let’s look at the challenges involved in BDD Done Right.
There are challenges in projects that are implementing BDD. Some of them are:
1. Expectations written too vaguely or too elaborately
2. Feature files not written in conversations with the business owner/analyst, developer, and the tester, but someone writes it and someone else ‘reviews’ it offline. That does not solve the purpose.
3. Specifications lying somewhere offline and not integral part of continuous development architecture
4. BDD used as a method for automation, and not used as a method for discussions and conversations to define product behavior
5. Business not taking sufficient time to sit down with the development team to come up with the feature files
6. Development hurries through writing of feature files, to mark things done
7. Push-pulls between development and testing as to how the feature file should contain, which leads to constant bottlenecks, instead of progress
It would be worthwhile to dig deep into the right ways of implementing BDD through conversations with stakeholders. BDD should not considered as test automation framework and should be used as behavior definition framework through conversations.
For strategies to validate and verify requirements definition and implementation, feel free to contact me.