“Is BDD Testing?” Yes!

This question was posed by Mark Winteringham at his blog. It’s a multipart series, and a great read.

Right now, the series isn’t done. I think there’s one final part coming.

And this post that I’m writing, right now, is scheduled to post in a few days.

I think Mark’s gonna say “No”. But, I could be wrong!

Best case, both of us think, “Yes.” Worst case, we’re thinking opposites. Either way, you get two viewpoints on the same topic.

New data. Very cool. It’ll be exciting to find out whether Dewey actually beat Truman* or not 😉

I’d like to answer this question, and also follow up with what could be the question under this one.

First though, some ground work:

What’s a Test?

The heart of the question requires a definition. What even is a “test”?

Well, first, we start with a hypothesis. This is just a proposed factual statement made about what you think might happen, given a set of conditions.

Could be anything. A famous example is, “What goes up, must come down.”

What we do with this hypothesis is we come up with an action to see if the hypothesis is true or false. When the action is performed, then we look for a certain condition to happen, to either prove or disprove the hypothesis.

So for the example above, we can just take an object… and toss it up in the air. What happei-see-what-you-did-therens? It falls back down, right? Hypothesis is true.

It helps tremendously to have this action be repeatable. So I hope the object wasn’t breakable or expensive.

But let’s take a look at some of the terms used before. Did you notice this?

given a set of conditions…
when the action is performed…
then we look for a certain condition to happen…

The language used in BDD is set up just like we’re trying to prove a hypothesis. It’s set up for testing. 

Yes, BDD is testing.


Why the Question?

I think the reason this question comes up is less about defining BDD itself, and more about defining ourselves as testers.

When new technology comes along that directly or indirectly affects us, you know, we gotta ask, “Is this something I need to be doing? Do I have to learn this or not?”

And if the answer to the question above is that no, BDD isn’t testing, then testers are less inclined to use the technology. We’re busy, so if something’s not really relevant then… eh, it can wait.

But, if the answer is that yes, it is testing, then yeah that can be a little scary.

Because we’re talking about a technology where we can write up a behavior in plain English… but there’s code behind the scenes that someone has to write, in order for BDD to benefit us at all.

Some BDD examples are sometimes really complex, and that can put some people off because they know, someone’s gotta write that code.

And every step we write that doesn’t match a previous pattern results in more and more code.

As a tester, if I don’t know how to code much (or at all) then the most I can do is write BDD scenarios to pass over to someone who does.

If that person ends up bogged down enough with writing the automation code to be driven by BDD, then eventually the stuff I write as a tester won’t be getting automated.

And then testers aren’t contributing directly to automation.

That’s where there’s a problem.

That Wall of Separation

There’s a term I use called Brain Juice to describe the different ways people solve problems.

Everybody has their own flavor of Brain Juice. Testers think about a product differently than a Business Analyst, a Developer, a Test Automator, a Product Owner.

Everyone contributes differently to make sure the product is awesome.

Automation helps us get through the manual grind quicker, which frees us up to do different things. Less tedium = more time = better quality.

I know I’m preaching to the choir on this, just setting the foundation.

If we can automate quick enough, there’s nothing stopping us from allowing everybody from contributing.

Even one automator, if efficient enough, with everybody slinging BDD at them for automation, everybody could offer their unique perspective.

But when we can’t automate quick enough, then we’re not allowing all those flavors of Brain Juice to mingle. There’s a smaller sample of ideas being automated, which results in us moving slower.

That’s actually a pretty pervasive problem, and I think a lot of companies don’t realize how big that is.

They may not realize there’s a correlation between what kinds of bugs squeak out to production, and what disciplines are empowered to help with test automation.

What if there’s a way to write automation so that you don’t need to write as much new code? Wouldn’t that bottleneck go away, and allow not just testers but everybody to offer their own perspective directly into automation?

Intriguing… maybe this is the bigger question to answer.

*The reference is about the American election of Harry Truman. A paper had tried to predict who would win and printed a bunch of papers to get ahead of all the other news outlets. And then they were wrong. The picture is of Truman lolling about the  mistake after his victory. 

This is the type of work I do with my consultancy. Coming in and refactoring frameworks to get the most mileage, or writing new ones from scratch, are crucial to the success of your testing effort. We have to automate at least some of our stuff–software’s so complex, we can’t not do it. Got business pain in this area? I have painkiller. Let’s talk. 


6 thoughts on ““Is BDD Testing?” Yes!

  1. I find the question of “Is it testing?” to be a little pedantic and not particularly helpful.

    The question I like a lot more is “what parts of this provide value and are they worth the cost?” I think you show pretty clearly here that BDD is useful and reducing duplication can help reduce the cost of development of an automation suite.


  2. Hi,

    I agree with what you’ve written here, however, I find it best when I write *and* automate the BDD step.

    As the only way to reuse code is when the Given/When/Then steps are exactly the same (well especially in my frameworks). If they are different we cannot effectively reuse code, e.g. “Given I have logged in” & “Given I have signed in”, these two statements will fundementally say the same thing but the code bindings to them will be different.

    Of course, I can change the bindings, however, this is a waste of time in my opinion and that could be time spent writing more scenarios with different permutations.

    That’s just one point I’ve come across with a 3rd party writes a BDD scenario for me to automate.


    1. Hi Kam–I’ve seen that too; different people write scenarios differently. Everybody’s style is unique.

      Something that saves time for me is using regular expressions in the binding, e.g.: “Given I have (?:logged|signed) in”. Could be expanded further (I/the user, has/have, etc.)

      It helps get tests done quicker, and also doesn’t limit people as much, on how they express the test should behave.


  3. I think specifications can be good enough to drive tests. I’ve been working hard to develop a tool to try and solve this using automation bindings that are themselves BDD specifications. I’ve had a lot of success with it so far and have blogged about it here if you’re interested:


    It’s a java app that you can just download and use ~ an interpreter and *not a framework* that requires coding!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s