Is BDD testing? Part 1 - A model for testers

Short answer, no…

Well, some of the activities involve testers, but it’s not real testing, right?

Look, it’s complicated…

Yes, yes, I know this is yet another post on BDD, but we need to talk about this. I’m not here to criticise, I’m here to understand — so please bear with me!

An introduction

Sarcasm aside, behaviour driven development is a big deal within software development and opinions on it are polarised. BDD started to gain traction just as I started contracting as an automation specialist, so I have a lot of personal experience of going from a misguided sycophant who loved misusing BDD, to an evangelised pitchfork-wielding zealot who was convinced BDD would lead to the death of tester — and I’ve been back and forth over a period of six years.

Whilst I’ve mellowed out over those six years, I must admit that until a year or so ago I still took a dim view of BDD, especially as my approach towards automation in testing has evolved. This resulted in a talk I gave at TestBash Manchester in 2016 called “The deadly sins of acceptance scenarios” during which I was hardly singing from the rooftops about how great BDD is, duly noted in this blog:

“The negativity around BDD or acceptance scenarios feels like the negativity I’ve encountered around Microservices and I’d like to hear some well thought out, positive experience reports. It feels like all of the balanced or thoughtful talks tend to be quite negative really and I don’t really see a great deal of value in using BDD over more straightforward approaches such as TDD…” (Matthew Bretten)

Matt’s observation is correct in that my talk wasn’t really giving the full picture of BDD and his comments resonated with some personal thoughts that I had on the subject at the time, namely:

• What is ‘BDD’ exactly?
• Is ‘BDD’ testing?
• Or is it something else?

My inspiration for the talk was based on the frustration of seeing so many mistakes being made with automation in testing, which I blamed on developers and testers not truly understanding the proper use of scenarios (which I still believe is the case). My intention was to highlight those mistakes, based on personal experiences, to show that others could use them as heuristics to help them see the traps they were falling into (which I still feel is useful).

But it was hard to write to talk. As I began putting it all together I was surprised by how much it challenged my ideas of BDD and scenarios. I found my understanding severely lacking in places. At first, it put me into a bit of a panic. But with some support from awesome people who answered my questions, I began to rebuild my understanding of BDD.

A model of BDD for testers

After my talk at TestBash Manchester, I felt I was too focused on scenarios and so I set myself the following task:

• Immerse myself in BDD literature to help me understand BDD better. Understand where testers’ misconceptions have come from and build a model that would make BDD clearer for testers.

And I have been immersed. Whilst I am by no means finished learning about BDD, I found creating the model to be a very useful exercise.

So, for this series of blogs I simply wanted to share my model of BDD in the hope that others may find it useful, to set them on the right path towards implementing BDD, and start a discussion. I also hope it will help others to avoid the traps testers fall into with BDD.

Here is my model. As you can see straight away there is a lot more to BDD than just Gherkin syntax and automation.

Look out for parts 2 and 3 where I’ll explore the collaboration and outside-in development parts of this model and attempt to answer the question: is ‘BDD’ testing?

Originally published at www.hindsightsoftware.com.