The topic of “Behavior Driven Development” has been on the agenda of testers and automation engineers for many years. The testing community splits into two camps.
The first ones say that: BDD “does not work!”, “There is no need for BDD!” and “Cucumber with BDD just adds redundant abstractions and layers!”.
The second part usually responds: “You are misusing BDD!” “It works for us!”. It turns out that the answer is just in the middle: each party is correct in some way.
Also read to this subject:
I have used BDD automation tools on various projects. At first, it was Specflow (C#), then there were Cucumber + BDD (Java, Scala), Thucydides (Serenity) + JBehave, built-in BDD in Rest Assured, Gauge (Java).
In addition to those I have listed, many more tools and wrappers use BDD approaches in different programming languages and platforms.
Why do many engineers not like this word – BDD? Let’s figure it out. All coincidences with real people and projects, please consider fiction. Of course, everything is different in your project, and BDD works. If such – please share your thoughts in the comments.
How is BDD sold to the customer?
Yep, in many cases, BDD seems like a “magic pill” that helps any team:
- The whole team follows the BDD paradigm (when a 3-amigo meeting gathers – and the tester, developer, and business analyst write these very “sacred” scenarios that are understandable to everyone. And this happens for each task in the product backlog);
- Managers and the customer can write business scenarios by themselves;
- The customer and other business owners can read the test reports and understand what was tested and what wasn’t;
- Testers can write scenarios very fast and then automate them;
- All team members can understand BDD tests, in particular, Cucumber BDD pair and contribute new ones (even developers and DevOps engineers – everybody!);
- The test team can get nice, beautiful reports out-of-the-box (hello, Serenity)!
- Automation engineers can easily change the test framework and leave the scenarios unchanged!
What is happening in the real world*?
*By the real world, I mean a typical big project in an outsourcing/outstaffing company.
- The communication chain becomes longer when there are oceans and timezones between development and business teams. But those teams need to deliver value and new features fast. BDD process either does not start working at all or fades as time goes on. A tester (or some invited Agile coach) may try to fan this ember, but the reality is usually cruel.
- If the team starts the BDD process, then, after a few months, the burden of writing and supporting Gherkin scenarios will be on the shoulders of the test engineer. As a result, the test engineer either plays an endless “ping-pong” with the business owner to clarify requirements or writes the scenarios by themself. When a tester asks to review the scripts, the usual answer from the business owner is: “I’m ok, let’s deliver!”.
- The company hires separate automation engineers if the tester does not have sufficient skills to write scripts and automation tests for them. The task of an automation engineer will be just the transformation of these exact scenarios into autotests. (Hello, routine!)
- The customer looks at the results of autotests and reports for some time. Maybe even praises how everything is clear. But over time, the only thing that becomes important to the business owner is what risks exist for the release. Nobody except the tester and QA Manager checks this lovely report.
- An automation engineer quickly realizes that the Cucumber with BDD layer only adds more “pain” to support. Scenarios grow and become monstrous panels of 30+ steps. It seems like you want to reuse the steps, but it’s not so easy. The automation engineer suffers (and polishes his CV in the meantime). Outside – there are many other projects without pain Cucumber and BDD.
- As a result, the number of scenarios exceeds conceivable and inconceivable limits. It becomes difficult to support them. The customer has already forgotten that the scripts are in text format. The only thing the customer cares about is fast feedback about risks for a particular release.
- When patience runs out – a magical team of senior experts comes in who quickly rewrite all this but using a simple and convenient code without BDD. These tests also run in parallel (locally or in the clouds)
- The customer is happy. The team rejoices. Management opens the champagne!
- And only somewhere in another company, the gray-haired automation engineer continues to flinch at the sounds – “Given, When, Then…”
Is BDD so bad? Maybe we are “cooking” it wrong?
There are some successful cases!
Many product companies successfully use the BDD approach, including Cucumber + BDD. So the teams are small, in one location. Business is interested in understandable scenarios.
If something is not clear to the testers, he will go and quickly “pull” the analyst to the next room and clarify the details.
Management looks at the reports’ details and thinks about each feature’s business scenarios. In the JIRA ticket, the description goes immediately in the Gherkin format.
Not only Gherkin!
Some other tools on the market provide the same abstraction as Cucumber but do not impose restrictions in the form of Given-When-Then. For example, the Gauge framework. With Gauge, you can write your tests in the free format. You can even store test cases as Markdown files and upload them to TMS as needed.
The text can be helpful!
In some cases, an additional text layer with a data-driven approach can benefit the team greatly. Test engineers can easily add new tests by changing only a few lines of code. These scenarios can be executed on multiple different platforms and browsers.
So is BDD good or bad?
The best answer is – it depends!
It depends on the way how you use the tool.
It depends on how the team works with BDD approaches.
It depends on whether you can admit that BDD is useless for your project and discard it in favor of another tool or framework.
It depends on whether you can apply an engineering approach to the testing or continue to suffer.
What do you think about BDD?
You may find Oleksandr by contact on the top and discuss the topic more closely as well 😉
