Black box testing vs white box testing - want to know my favourite?

Zoe King is a Senior Tester at Razor and she’s here to share her awesome insights on black box testing vs white box testing.

OK, so I know you’ve landed here because you have some burning questions about black box testing v white box testing, and I’m excited to share my thoughts on the different methodologies, but first let me introduce myself.

My career pathway to being a software tester might be considered slightly unconventional. I come from a scientific background, I used to be a Laboratory Scientist and then a Genetic Technologist before joining the Razor team as a Test and Data Analyst. This means I’m incredibly methodical and detail orientated, which is my superpower in software testing!

I love being part of the software testing team at Razor, I work with great people and I get to discover potential bugs that, if made live, would negatively affect the user experience.

So, let’s get the difference between white box and black box testing.

What is white box testing?

White box is software testing that’s done from a developers viewpoint. We have full visibility of the code and can see how things are actually working behind the scenes.

It’s called white box because you get to see through the programme's outer covering (or box) and into its mysterious inner workings. Imagine you’re looking at a TV that’s broken. When you’re trying to fix it you take the back off and can see all the wires that make it work, which can help you find the issues and fix them.

White box testing also provides more opportunities for using automation testing, which can help improve the accuracy of testing and allow bugs to be found quicker.

White box testing allows you to conduct deep and thorough tests, and identify any bugs from the developer’s point of view. Understanding code and development techniques are really important here.

What is black box testing?

Black box testing is different because you don’t have visibility of the codebase. It’s called black box because you can’t see through the programme outer covering (or box). If this was a TV, you wouldn’t be able to see the wires or understand how they work. You don’t know what’s going on inside or how things are interacting with each other. But that’s the whole point of this approach. You’re interacting with the tech as though you’re the end-user.

But don’t get me wrong, just because you’re doing black box testing doesn’t mean that you don’t understand what the tech is doing, you still understand what it is meant to do. You just don’t see how it all connected and working behind the scenes.

You can also include some automation testing when you’re testing UI (User Interface) by running automated tests in a browser instead of manually doing things like logging in. Which is awesome as it saves me loads of time.

Which testing method do I prefer?

As software testers, I like to think of us as the last line of defence. Our awesome development teams work incredibly hard to create awesome tech but bugs are inevitable. It’s our job to catch them before they’re released to the public. We’re all part of the same team!

From a classic testing perspective, black box is great! If you don’t have preconceived expectations on how something should work, you can clearly assess how it actually is working. You’re removing the logic-based stuff from the actual scope requirements and disassociating them in testing.

I’m really interested in quality and I think that stems from my scientific background. That’s why I love black box testing. I get to put myself in the shoes of the user and experience the tech as they would. Discovering any issues they might encounter and reporting them for fixing.

As software testers, we’re gatekeepers and we don’t want anything to get past us. How awesome is that!

Want to know more about our work and how we’ve helped our clients with their digital transformations?