Anton Angelov
Sep 6, 2018 · 3 min read

Thursday Thoughts on High-Quality Test Automation- Why BDD is an unnecessary evil Part 1

I decided to start a new series about sharing my thought on high-quality test automation called- Thursday Thoughts on High-Quality Test Automation.

Don’t worry I will try to keep them relatively short. I will continue to write the long articles. Just not everything I want to share with you can be included in these long publications. I prefer to share it when it is on my mind not three months later.
— — —
The first topic I chose to discuss is why BDD is an unnecessary evil. If you read my last article- Generations of Test Automation Frameworks- Past and Future, I talked in short about that. (btw I think this was one of the best things I have written till now)

I am sure that some of you are fans of BDD. I respect that. It wasn’t going to be so popular if it didn’t have some benefits and maybe is working for some people. However, I haven’t seen a team where this worked as promoted.

For me, the whole thing behind this BDD is the promise to the non-technical QAs that they will focus on the writing automated tests instead of the low-level details. Even they go even further promising that business people will read and also write these tests.

For me, this technology tries to solve the problem completely wrong. Why?

Because as you can find in the mentioned article, in the current world of fast-pace-changing technologies to be able to create proper automated tests, you have to know how to code. Even the whole Gherkin syntax or BDD alternatives are actually coding. How on earth can two people always write every sentence in the same way? You still need to learn the special syntax and the repository of available words, verbs and sentences.

Look at the following Gherkin sentence:

Fill billing info- Anton Angelov, Bulgaria

And the second variation:

Fill billing info- Anton Angelov, United States, New York

This sentence should be bound to the same method with a much-complicated rule for it (usually using a regex pattern).
This is only one of the problems coming from BDD. If you use another verb for the same action, the binding methods won’t work. If you don’t know how to code, you have to notify the framework developer to include this binding. But imagine that this person is in a meeting, went earlier home or is on holiday? Even if he/she is there, this doesn’t mean that he/she will have to time to include it immediately.
The same is valid for troubleshooting tests. If you don’t know to code, I bet you won’t know how to read the code and debug it. A big part of the test automation engineers’ time is dedicated to fixing and maintaining existing tests. Even this time is much longer for some teams than writing new tests.
End of part 1, let’s continue next week since I promised shorter emails.

Main Lesson from part 1: start learning to program, coding can make you much better QA (this is true if you want to write automated tests). It will make you much closer to your programmers. You will have common topics. (the harsh truth is that technical QAs get much bigger salaries)

Anton Angelov

Written by

Co-Founder and CTO http://automatetheplanet.com Inventor https://bellatrix.solutions/