So, what is this BDD testing stuff, anyway? Before I answer that (as it turns out, nonsensical) question, I’ll speak briefly about the sometimes-frantic world of software development trends.
It seems that, methodologically, software development reinvents itself at a staggering pace. First there was software development, and then there were formalized processes, like the Rational Unified Process (RUP). Then we went agile, but that wasn’t quite enough, so we scaled agile, got lean, and started doing something ominously called “mobbing.” And that’s just on the process side, with workflows and collaboration models.
When it comes to development techniques, we like to let things drive development and design. The last couple of decades have brought the emergence of test driven development (TDD), acceptance test driven development (ATDD), domain driven design (DDD), and behavior driven development (BDD). This all makes for a fairly manic pace of change.
I attribute this largely to the relative youth of software development as a profession. Things like accounting and physics have been around for hundreds of years, so the basics have solidified some. With software, we’re still working our way there.
And this frenetic pace is a double-edged sword. It’s good because we’re rapidly evolving, improving, and maturing. But it’s a challenge when you need to separate the important developments from the flashes in the pan. And it’s especially challenging for those in collaboration with the software developers, trying to understand how changes to software development techniques impact them.
And so we arrive at the central question of this post.
If the development organization starts to make noise about BDD, how does it impact you? How does it impact the overall testing strategy?
Get TestRail FREE for 30 days!
To Understand BDD, Understand Unit Testing
Don’t worry. I’ll get to what BDD is shortly. Before I can do that, though, I need to cover an essential prerequisite: unit testing.
If you earn a living testing software, there’s a pretty good chance that you’ve heard the term “unit testing” in regards to something that developers do. There’s also a good chance you’ve regarded it somewhat suspiciously, wondering if the developers aren’t wasting time doing your testing job instead of, you know, developing the software.
But, as it turns out, there’s no conflict here. Developers are, in fact, doing a form of testing when they do this. But they’re doing something both very necessary and very granular, and it involves writing code.
A quick analogy will help understanding. As hypothetical “car tester,” you might check on things like the following:
- Does the car start when I press the ignition button?
- At highway speeds, does the car run normally or is it noisy?
- Do all of the doors and windows open and shut easily?
You get the idea. If this is your job as a “car tester,” then here is what the “car developers” are doing when they write unit tests.
- Does this particular engine component heat to this particular temperature?
- If we apply a certain amount of current to the dashboard light fuse, does it safely blow out?
- Are these screws Phillips head?
Unit testing is the developers checking their work with automated tests. They write these tests and run them, and they’re so granular, specific and low-level that they make sense to no one outside of the software development group.
What is BDD?
With a definition of unit testing in the books, we can now make our way toward BDD. Unit tests are granular, automated things that run quickly and test code in isolation. And, a couple of decades ago, some pioneers of the TDD technique had the idea to write these tests as they wrote code instead of afterward.
Test driven development (TDD) has many benefits, all of which are beyond the scope of this post. So without delving into the motivations, let’s just say that TDD forces you to articulate with a test what the code should do, before you actually write that code. In a sense, it’s like the scientific method. Before you start with the “experiment” of writing your production code, you form a “hypothesis” of what the result should look like.
Behavior-driven development (BDD) is an evolution of TDD. It’s a development approach that produces more business-centric tests.
TDD practitioners enjoyed the benefits and cadence of the practice, but started to think, “what if we applied this beyond the most granular, nuts and bolts concerns? What if we articulated requirements in natural language and followed the TDD approach? And what if we involved other stakeholders outside of the development group?”
A BDD scenario might proceed this way.
- You have a user story that someone should be able to log into your site.
- You take that story and express it in “given-when-then” format. “Given a valid user account, when I submit its username and password, then I should see the logged in homepage.”
- The development team writes code that translates this statement into an actual automated test that can pass or fail, and it starts off failing.
- They write code until it passes.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Why BDD Helps
Let’s take a breath and think about this for a moment. It has some weighty implications.
When you successfully execute this approach, you have a natural language expression of a requirement and an automated test that passes or fails depending on whether or not the requirement is satisfied. This means that you have a very specific definition of done for each requirement.
How many meetings (arguments) have you had over the years where different stakeholders in the software development process argue over whether the software satisfies a requirement or not? I bet it’s more than you can count.
“Look, it does what the spec says. Users need to be able to log in, and they can log in. There’s no bug.”
“What do you mean there’s no bug!? It takes them back to the login page! They have to manually type in the home page URL, and they have no way of knowing they’re logged in!”
“Well, technically, that does fit with the spec.”
When you follow a BDD approach, you bring the stakeholders together ahead of time and get them to agree on what it means to satisfy a requirement; exactly what it means. The developers then codify this into an executable and measurable test. The corpus of all of these BDD tests then tells you at a glance whether the software satisfies all requirements or not.
How BDD Affects Your Testing Strategy
So with all of that in mind, how does BDD affect your testing strategy? Well, in the very beginning of the post, recall that I said that “BDD testing” was nonsense? It’s time now for an explanation.
Behavior driven development is a development technique that happens to produce automated tests as a byproduct. So “BDD testing” is nonsense because BDD is not truly a testing strategy, but rather a way to define and verify that a requirement is complete.
And that tells you everything you need to know about the impact on your testing strategy. Since BDD is not a software testing strategy, per se, you still need your testing strategy. You still need exploratory testing and regression testing. You still need smoke testing, load testing, and performance testing. And you still need intelligent humans to do all of these things.
BDD doesn’t give the QA folks an extra thing to do or an extra task to complete. Instead, it involves them earlier in the process and gives them an important seat at the table during discussions of “how should this behave and how do we know when it’s done?” BDD fits into your testing strategy by forcing agreement from all stakeholders on what, exactly, to test. Check out our others posts to dive deeper into BDD, TDD, unit testing, and more.
