BDD — How it can go wrong

(from a tester’s perspective)

Let’s face it! Nowadays we all use Behaviour Driven Development as a process to develop a feature. This is the trend. And as a trend, it sometimes can be not very well established, or we can mimic ways we read or heard about somewhere, without having understood the essence of it.

I just want to share with you my experience of a few ways on how BDD can go wrong. What I did wrong while trying to learn on how to do it.

As a tester, I wrote down the BDD scenarios on my own

Yeap. That’s right. Now, imagine this. We have a User Story with requirements in free text written by PO and scenarios in BDD written by testers. This can lead to several different things, which can go in circles forever:

  • We can review requirements and BDD scenarios between PO and Tester forever. We get confused and lose time explaining to each other what we mean
  • We will end up with two references on what to implement: the requirements and the BDD scenarios, or even worse:
  • Devs probably will never pay attention to the scenarios.

So the benefit of 3-amigos logic of collaboration is lost!

We tend to forget that the main purpose of BDD is to be used as a tool to collaborate. It is a tool of creating a common language, that we, as a team of different roles, agreed upon. That we stay engaged on what we create, from moment ONE of SDLC till the end of it. And it seems we make our lives more difficult this way.

As a tester, I wrote down the BDD scenarios during the testing phase.

Even worse! Now everyone gets confused. We have back and forth in the cycle between requirements analysis, development and testing phases. Usually, someone misses the changes. We forget to inform the whole team of what has changed. We change estimations. We realise we have missed something in the implementation. We miss deadlines that we promised. And this tornado can go on.

We see the “bad bad bad” face of Agile. And BDD seems like a complexity and not like a tool to simplify things. We don’t drive the design of the system based on behaviour, as BDD indicates.

As a tester, I went too deep in describing the implementation

This can be a nightmare. Usually testers test on System testing level, do Black Box testing: We must know nothing about implementation. Instead of describing the scenarios on a domain specific language (Gherkin), explaining WHAT we want the system to do, I started describing it on the developers’ perspective, aka HOW we want the system to do it. At the end, many times, PO should compromise, or create a new User Story to cover the created gap.

But even if we test on a lower level (e.g. integration), BDD should be used to create executable specifications, not implementation details. It should be readable and understandable from every team member.

Can you see how important is the role of the PO and testers on this point? To train the technical team to think a feature as a whole, and not as a part of code.

If you can’t explain it simply, you don’t understand it well enough — Albert Einstein

As a tester, I thought User Behaviour (aka UI interactions) are the Behaviour

This was my very first scenario, that I have also automated

Given the login page loads

When I enter “markella” in the username field

And I enter “mypassword” in the password field

And I click enter

Then the home page loads

This can only be used for UI testing. What about API? Should I write a different scenario?

Unfortunately the answer is yes.

And what if the implementation changes? What if, in the future, we want a system that can login with voice recognition? Should I go back to the scenario and change it ?

Again the answer is yes.

This is not maintainable. And it doesn’t help us to understand on what level we should create a test to cover the requirement: On UI? Or can be covered on API as well? We create duplicate tests, we create too many non maintainable steps (especially if we use automation, this can also go really wrong). And as we go away from the code, less people will understand what a feature does.

This test could be something so simple as this:

Given “markella” is an authorised user

When “markella” tries to login in (his)(her) account correctly

Then “markella” has access in (his)(her) account

This is not UI specific. It describes a clear behaviour. And, together with the previous point, it hides all the implementation and can be much more maintainable and understandable at the same time.

As a tester, I tried to automate everything with BDD

Well. Testing frameworks that use BDD usually have more levels of abstractions than a simple framework. This means that if we try to automate every little detail of the system, without having carefully thought about it, we can end up with too many steps or even duplicated steps we won’t even remember what they do one day. It also doesn’t make much sense for me in a lower level testing. As an example, imagine a unittest or API test written in Gherkin. Why should we do this?

No. This is not useful. BDDs should be specifications. We should always start from business behaviour. And the scenarios should be few, described as examples, and to the point.

To sum up

BDD is a very powerful approach to develop a feature:

  • It can reduce unnecessary communications and hours of meetings, giving the same perspective in all different roles.
  • It can specify really well a system, especially with the use of examples. Keep it short.
  • It can create strong bonds within the teams.
  • It can give a sense of engagement for each member.
  • It is so democratic.
  • It can help us having living documentation by automating the specifications.

There is not exactly one way on doing it. I have tried to share on what to avoid, hoping that you can find your own way a little bit faster and with less obstacles.

You can also find some great tips here:

Automation Panda BDD



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store