Why Behavior Driven Development Is Not About Testing?
Few days ago an interesting article popped up on my Linkedin page. The article was about Behavior Driven Development (BDD). The author tried to explain when BDD is not the right fit for your team. Among first couple of situations were stakeholder’s lack of interest in engagement and pressure to deliver fast. The comments in the article led me to believe that most people in software development domain fundamentally misunderstand BDD. Most of them equalize BDD with test automation technique and quite often claim that BDD doesn’t work or it is too much overload with no results. So, why Behavior Driven Development is not about testing?
The Definition
Okay, we are not quite going to stick to some rigid definition of BDD, but instead let’s understand the process behind it. BDD as its name says is a software development technique. Behavior Driven Development is not about testing, although some of the outputs of BDD can be useful in test automation. It starts with a collaboration between all members of a team, including technical and non-technical members. This means that developers, software architects, QA engineers sit down with business analysts, product owners and subject matter experts and create a constructive dialog about the future software. It happens before the development starts and it is a continuous activity in the development process. This process can have a name like Three Amigos (BA, QA engineer and developer) but it is not necessary to call it that way.
The Aim and Benefits
The main purpose of BDD is for all sides to align on things related to future development. Business analysts write their requirements without real knowledge on technical abilities of the software or the technologies in use. These meetings are a good opportunity for them to realize that they need to change something to accomodate a technology limitation for example. Another good opportunity for them is to discuss directly the alternative approaches for their requirements. Quite often a refinement of aceptance criteria happen on these meetings as well.
For developers and quality engineers this is an opportunity to ask questions about edge cases. We always need to cover some edge cases in software behavior. These cases, user flows and scenarios are often not part of initial requirement document. The other part of these meetings may be generating use cases in Gherkin format which can be used in test automation. This part is not mandatory and for the successful implementation of BDD we don’t have to use Gherkin at all. This is a common misconception that Gherkin is mandatory in BDD. It certainly can be used and applied in test automation, but this is not a requirement for successful BDD implementation. It does not mean that you shouldn’t make automated tests. You should, just without Gherkin.
What BDD is not?
BDD is not something a test automation engineer should implement at all costs. A common mistake is to implement Cucumber with Gherkin in test automation even if you do not engage with developers and product side of the team. Using Cucumber and Gherkin will not make your process BDD. It takes a lot more than that to implement BDD on your project. I have been told once that using Gherkin and Cucumber in UI test automation help non-technical people read your tests. This is nonsensical to me. I don’t know any non-technical people who would go anywhere near tests. It is simply a waste of time to use Cucumber if you do not use entire BDD.
To go back to introduction and the fact that there are some organizations where the main stakeholders do not take active participation in development. If there is a role in the organization called a product owner, business analyst, subject matter expert or product manager it is their responsibility for delivering value to the client. As mentioned before, there are always new questions during development. We start development from known facts and later we make changes as our knowledge about the problem grows. To understand the problem we are trying to solve, we ask questions to people on the business side. If they are not willing to share their expertize with us, then the entire project is doomed. If they don’t have time to work with us, then the project planning is wrong. In these cases, it doesn’t matter if you use BDD or anything else, you are set for failure.
The use of Gherkin
Gherkin is a domain language created to be used by all members in a development team, technical and business side. The idea was to have a common language for both technical and non-technical people in the team so they could address the same thing using the same set of terms. In BDD Gherkin is a common way of documenting use cases and explaining the specification or requirement. As mentioned before, it is not essential in BDD, meaning BDD can be successfully implemented even without it. Some companies have their own terminology/domain language they tend to use in BDD meetings which is perfectly fine as long as the outcome is the same. The aim is to explain what the system does, but to leave out how it does it. The implementation of the solution is not a part that should be written in these meetings.
Feature: Guess the word
Scenario: Breaker joins a game
Given the Maker has started a game with the word "silky"
When the Breaker joins the Maker's game
Then the Breaker must guess a word with 5 charactersFinal words
There is one thing to underline as a conclusion, Behavior Driven Development is not all about testing. It does help with testing immensely. It helps you understand the problem the software should solve. By understanding the problem better, you can design your tests in a better way. It helps the team to identify the acceptance criteria which then help with creating tests. Another takeaway from this article is not to use Cucumber and Gherkin if the entire team didn’t participate in writing the Gherkin feature files. It simply puts stress on the test automation engineer and it does not provide any significant value.
