This article is about to simply describe what Behaviour Driven Development(BDD) is without mentioning all the terminologies that might exist in any source around this methodology.
My simple definition of Behaviour Driven Development(BDD) is:
Behaviour Driven Development(BDD) is the collaboration process between business and development team in order to be on the same page with requested features and produce software that matters.
Let’s see with more details the above definition.
Usually, business requests new features from development team. Most of the times, business doesn’t really know what the project is capable of. Here the development team comes to let business know if the requested feature is possible to be implemented. In order the development team to provide these details, it needs to ask business some questions to fully understand what the business actually requests.
The best way for development team to have a good understanding about requested feature is to ask for examples. Asking examples from business helps you to understand better, keeping notes based on these examples for future testing of the behaviour of your application, estimate the development time more accurately and also keep business and developers on the same page as both sides know what the application behaviour is going to be.
The following image depicts this practice.
There is a terminology about this that it’s called Ubiquitous Language.
Ubiquitous language is a language created by developers and the business in order to discuss features and talk effectively in examples.
The most common and adopted format for examples is Given–When–Then
Below is the definition of all of them.
- Given describes the initial context for the example
- When describes the action that the stakeholder performs
- Then describes the expected outcome of that action
Before you start writing examples for a new feature it’s also helpful to mention on the top of the examples page the feature description, the business value, who benefits of the feature and what the user will be able to do.
See below a sample of an examples page. I have written down the feature details and a scenario/example.
In the feature examples above, I refer to how to manage a TV channel list for storing or removing channels to/from it. This could be a separate feature examples for adding, removing a channel but also the channel list could include more functions. In this case, I would like just to show you how the structure of the feature examples should be.
Because sometimes we want to extend our example about providing more initial context, input actions or expecting more outcome then we can extend them adding And or But under Given, When or Then.
I have added an extra line with And after the Then for making sure that the latest added channel has been added in the channel list.
Using Ubiquitous language for writing examples for a new feature is a good way for everyone to understand how many details the feature should have in order to be implementable, see possible flaws happening in the system before development commences and finally to realise if the new feature matters for the users.
If there is not this kind of discussion before any implementation of a new feature, possibly business and development team will not be on the same page as they might think. This is happening because some words have different meaning for business and developers as a result when the new feature is delivered then the behaviour of this feature is not what the business was asking for.
This misunderstanding is called Cost of Translation.
See an example of Cost of Translation in the image below.
Regarding the meeting between the business and the development team, for more efficient result QA testers can fit in order to highlight possible flaws happening in the system before the development starts.
This practice is called The Three Amigos.
In order to deliver software that matters, a good communication needs to happen between all the entities that get involved. Collaboration between the business and developers is the key for avoiding misunderstanding, having a clear idea about what needs to be delivered and tracking the process of the feature from the beginning till the end.
Find out more
Below you can find my presentation about BDD that includes more details, examples and terminologies about this methodology.