Does BDD Help With Manual Testing?

This question came up recently, and it's a good one.

The answer is YES.

If you're a manual tester, or just getting into automation, BDD can feel a bit intimidating.

But it turns out, it can be a?fast track to more effective agile testing,?even if you don't write a line of code!

How so?

Well, there are?two main ways?that BDD pratices can help with manual testing.

The first benefit is probably the biggest one.

The BDD process (not the tools, not the automation, not the Given..When..Then format, but the process) is designed to?build a shared understanding?of the requirements, and?uncover the things you don't know?early, rather than later.

So when you pracice BDD (properly!), your team?take deliberate action?and get?a much more solid understanding of the requirements?they are trying to build, before they start building it.

And this is a game changer.

Even if you do zero test automation. Even if you only focus on manual and exploratory testing.

Why?

Let's dig deeper.

In BDD,?everything starts with a conversation. Teams that practice BDD get together before a sprint starts. They talk about how the user will interact with the application to get their job done, and about the business rules and constraints that apply.

And they identify a few key examples that can be used to prove that the feature does what it's supposed to do.

But they don't just chat over a coffee - it's a deliberate, structured conversation with well defined methods.

There's a bit of an art to doing it, but it's pretty easy once you know how.

And automation in all that?

Well, the automation side of BDD speeds up the feedback cycle and automates the release evidence - it lets you know when a feature is done, and gives you some evidence that it actually works, automatically.

But?the real value isn't the automation itself - its knowing what to automate.

Because if, as a team, you know what to automate, you also know what to test.

And if, as a team, you know what to test, you also know what to build.

And you (as a team) are likely to get the job done?faster, and make?fewer mistakes, because you (as a team) spent time thinking about all those scenarios and edge cases before you started the work.

That's one of the biggest benefits of BDD, and it doesn't need a line of automation code.

And the second benefit?

Well, even if all you do is identify your acceptance criteria and write them in a rigourous, structured testable format, even if you don't automate them straight away, it gives you a powerful basis for your manual and exploratory testing.

You start with the acceptance criteria (does the feature do what it's supposed to), and then you fan out from there with your exploratory testing.

And this is much more efficient, in my experience at least, than the old-school approach of writing reams of manual test cases in an Excel spreadsheet or some test management tool, then going through them one-by-one like a robot.

Give it a try and let me know how you get on!

If you want to get a better understanding of how BDD practices can help you as a tester, whether your team is actually "doing BDD" or not, then take a look at the brand new?BDD Blueprint training, which covers this and much more, including:

How to run requirements discovery sessions faster?(and save time for yourself and for your team!)

How to find more edge cases and tricky scenarios?that would normally only be spotted during development or testing (or even in production!)

How to eliminate defects before they happen?(and bring your unplanned rework right down as well - some teams see defects drop by 80-90% using these techniques)

How to make writing automated acceptance tests faster and more reliable?(it's VERY hard to do in-sprint test automation without using these techniques)

You can grab the BDD Blueprint training here.