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 happens? 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.