Before we dive into BDD and the three stages of the textbook BDD process, let's have a look at some of the most common misconceptions that people have about BDD
First of all, BDD is not a testing activity. While testers and testing play a pivotal role in the BDD process, BDD is an activity for the whole team. It revolves around communication, and around making sure that everybody is on the same page with regards to the expected behaviour of a new feature or of a new software system
Second of all, BDD is about much, much more than just automating acceptance tests. I see a lot of people and teams claiming that they are practicing BDD, when all they do is sticking a Gherkin layer on top of their predefined or existing test automation code.
That is not BDD.
That is sticking a Gherkin layer on top of your predefined or existing test automation code.
Now, while tools like Reqnroll are very powerful and can bring a lot of value to your software development process, the true power of BDD is in communication and having meaningful conversations about what the software that you mean to develop is supposed to do.
Reqnroll and automated acceptance tests can help you verify afterwards whether or not the software you built conforms to the specifications and the behaviour that you defined and discussed before starting development, but it's definitely not the only part of the BDD process
Third of all, BDD is not for everybody. While it is a very powerful methodology that can help you clear up misconceptions and misunderstanding about how software is supposed to behave as early as possible, it might not work for everybody, and it might not work in every situation or for every context.
Just like Agile, Scrum and Kanban, BDD is a methodology, and methodologies tend to work better in some contexts than in others. SO, before you decide to do a full blown BDD implementation, please make sure that it is the right methodology for your team and for your context.
For example, by doing a proof of concept, or by running a pilot project with a development team of your choice.
Finally, as with any methodology, there is no one right way to do BDD. I like to present BDD as a toolbox, a set of tools and principles that you can adapt to your own context and your specific needs. So, pick from the BDD tool box what works for you, what fits your context, your team and your organization, adapt that as you see fit and leave out or stop using what does not work for you. Don't be afraid to experiment!
Having said that, there is such a thing as the textbook BDD process, and this textbook BDD process consists of three separate stages. In this course, we'll go through all three of the stages and we'll take the feature that we want to add to our online banking system through each of these stages.
Of course, before we even start working on a feature, we should have some level of confidence that that feature is going to add value to our product, to our process or maybe even to both.
The first stage of the textbook BDD process is called Discovery. This is where the important conversations take place, this is where we come up with examples that illustrate the desired behaviour of our software, and this is also where we create a shared understanding where we make sure that all the stakeholders within our development are on the same page regarding what our software should and should not do.
The second stage of the textbook BDD process is the Formulation stage. This is where we take our examples and we turn them into specifications that document and illustrate the requirements and the expected behaviour of the feature or system that we're building.
And in the third and final stage of the textbook BDD process, we're going to turn these requirements into executable specifications and living documentation, or in other words, we are to going to create automated acceptance tests, using tools like Reqnroll, to automatically verify that the software that we have built conforms to the specifications and to the behaviour that we defined and discussed earlier in the process.
In the next couple of chapters, we are going to look at each of these stages of the BDD process in more detail, using the planned loan application feature of our online banking system.