Having worked as an independent consultant and trainer for almost 15 years now, I’ve seen a lot of teams and organizations considering adopting Behaviour Driven Development (BDD) as a way to improve their software development and delivery processes.
Sometimes, this worked out really well, for others, it was a bit more of a struggle, while yet other teams and organizations chose not to adopt BDD at all in the end. And that’s OK, of course. BDD is definitely not a silver bullet, and adopting it will take time and effort from everybody involved, both those in the software development teams as well as their stakeholders outside the team.
The teams that have successfully adopted BDD have seen a number of tangible benefits as a result. In this blog post, I would like to highlight five of those benefits to show you what you and your organization, too, could gain from implementing BDD as an underlying process for your software development and delivery.
A significant part of defects in software, and frustrations from end users when software is delivered to them, are not the result of a developer making a mistake, but rather by incomplete or misaligned information that is given to the developer when they are asked to implement a feature.
In other words, it’s not the software itself that is broken, but the root cause is rather a communication problem. One of the main goals of BDD is to address these communication issues by making alignment between business people (such as Product Owners or Business Analysts), developers and testers an early and vital part of the development process. These so-called ‘three amigos sessions’ are meant to scrutinize and improve the specifications from three different angles by removing ambiguity from and identifying gaps in the specifications. As a result, all parties (amigos) involved have a shared understanding of the desired behaviour of the feature to be built, and this makes it much easier to create crisp and clear specification documents (feature files, in Gherkin format). This should lead to fewer reported issues that can be traced back to communication issues.
When ambiguity is removed from your specifications, and all angles have been covered in coming up with the specifications, the chance of them being meaningful and correct vastly increases.
Especially when BDD is combined with an Agile way of working, where software is delivered iteratively in small increments, your documentation is continuously read, edited and improved. This is a big improvement over traditional software development paradigms, where designing everything upfront, delivering thick and detailed design documents and then spending months or even years deviating from those specifications for various reasons made it much harder to keep the documentation meaningful and correct.
Tools like SpecFlow can be used to support the BDD process by turning the specifications, written in Gherkin feature files, into executable code, which can then be used to drive automated acceptance tests for your software.
This is what’s known in BDD as ‘living documentation‘. Because the specifications are directly tied to the implementation of these tests, it’s immediately clear which business outcome is impacted when an automated acceptance test fails. When proper attention is paid to the maintenance of the automated acceptance test suite, this positive effect will remain long after the implementation of the actual feature.
Using BDD, supported by SpecFlow or another tool, provides a strong link between specification of a feature in feature files and automated acceptance tests.
This makes it a great fit with Continuous Integration and Continuous Delivery practices, as well as DevOps. These practices thrive when automated tests are in place that provide fast and clear feedback to all stakeholders involved. SpecFlow is a code-based library and an integral part of the automated acceptance test code base and as such, its integration in automated build pipelines is straightforward. And since SpecFlow can be combined with a wide variety of test tools, developers and testers can choose freely how they would like to automate their acceptance tests, without compromising the way Gherkin is written.
Finally, adopting BDD could also lead to a higher quality of the code base of your application.
There’s a good reason developers should be involved in the three amigos sessions, where the shared understanding and the shared language are created and refined. This will allow them to keep the business entities and terminology in mind when they’re writing the code that makes the specification come alive. If everybody knows what is meant when the specification refers to ‘an active account’. developers can use this knowledge to model the implementation using this terminology, for example by creating an Account class with a property ‘active’. There’s a direct link between the specification and the implementation, which will make it much easier to understand what the implementation does. This is very useful when onboarding new developers, for example.
Now, as I said in the beginning of this article, BDD is definitely not the holy grail of software development processes. However, the reasons mentioned above should be helpful when deciding whether or not you want to implement BDD.