White Box Testing Vs. Black Box Testing

white-box-vs-black-boxA casual analysis of software testing tends to break it down into main categories — black box testing and white box testing. This distinction a bit strange though. Does it really exist? Do we really need it?

White Box and Black Box Testing Seem Opposite

White box testing and black box testing seem to be completely opposite each other based on name alone, but what do the terms really mean?

The ‘box’ part of this phrase includes everything that goes into making your product work — code like Java and the compiled jar files, HTML, CSS, and JavaScript, the servers and computers this code runs on, the database and files where data is stored, and the tools you use to access the software.¬†Today that mostly means a web browser.

A black box means that you cannot see, or do not have access to, any of the inner workings of the product. You experience and test the product at the exact same level your customers do, the user interface.

Black box testing is a lot like inspecting presents on Christmas morning. You walk up to the tree and see packages stuffed underneath the tree, each wrapped and labeled a little different. You can pick them up and feel how light or heavy they are, or shake them and hear the insides rattle around, but you don’t get to see what is inside (till a little later at least). Your whole perception of that package is based on information you get from outside of the package.

White box means you get a little, or a lot more, than a superficial view of the product. The focus of white box, is what is inside. If a page fails when you click the submit button; you can open up the chrome browser tools and see the javascript error, you can open up your favorite REST API client and POST different data to see what happens, you can go to the database to see how much if any data made it in, or you can interact more closely with the code through unit tests.

Basically, you can do anything you want.

The point is that you go deeper than the user interface. As deep into the product as you need to go in order to learn what you need.

The Technical Side of Testing

Software testing happens on a spectrum in most ways — approaches, techniques, and distinctions like black or white box.

When I test software, I start at one point, usually in a browser these days, and depending on what I find and what looks interesting I may venture into the database to see how data the data fits together and whether it is being stored correctly, I might open up developer tools in the browser to learn about JavaScript problems or to learn about the DOM, or I might go sit with a developer so we can step through the code line by line to learn more about a problem.

Other times I’ll use frameworks like frisby.js to help me test a part of the software that lives below the UI, the API.

My focus is on using the appropriate tools to learn important things about the software I’m testing.

A lot of testers tend to be more comfortable when doing less technical work, at least early on in their careers. The closer they get to the black box part of the spectrum, the more comfortable they are.

It is hard to deny that our field is asking for more and more technical people. Take a look at some local job advertisements and count the number of positions focused on test automation, or performance, or have the acronym SDET somewhere in there.

Learning these technical skills in addition to being a great tester means you can move around the spectrum as you please; it also means that you will discover more and better opportunities when looking for a new job.

Software Testing Terminology

The truth is that this distinction has never really mattered. No one ever stops before opening Chrome Developer Tools and says “OK, Grey Box Testing! All teams go!”. The change over from treating a product as a black box, to digging deeper bit by bit from the document object model (DOM), to the database, to the source code, happens fluid as you need it. I can’t ever recall a time where I had to report on whether I was doing white box, black box, or something in between during a status meeting, in a bug report, or when explaining strategy to executives.

There may have been one time, a long time ago, where I was asked about the definition during an interview. Now that I think about it, we mostly talked about definitions during that interview. I still ended up with a job offer despite not having the exact definition they wanted.

There is no standard language in software testing, we are still developing as a field. Black box and white box are abstractions, words we use to describe to describe very general things, like the economy, rather than concrete ideas. What does matter is that when I (or you) hear phrases like this, we ask the question “What do you mean by that?”.

Immersing Yourself in Developer Culture

If you currently find yourself testing mostly on the black box part of the spectrum, now might be a good time to start getting a little more technical. I have found a lot of people do this initially because someone, probably a manager, told them they need to automate testing, but that is a difficult path. Starting from the technology, tools tend to treat the browser or application as a black box – start it up, send it data, and see the results. This has a steep learning curve for people that have never written code because, as you have learn and apply so many new concepts all at the same time.

Personally, I started moving more toward the white box side of things by immersing myself in developer culture. I attended code reviews, went to local developer meetups and conferences, and tried to hang out with developers more daily. This allowed me to absorb terminology, concepts, and attitudes about terms and languages really quickly. After being immersed for some time, I picked a project, a small one, to work on. Since I had been around the conversations for a while, when I had a problem at least usually I knew what questions to ask. If I didn’t, well I had developed a relationship with some developers and they were a little more willing to help out since I showed real interest.

Now that you know the spectrum exists, maybe you can spend some time going deeper. Learning to be technical is a lot like learning to play an instrument; no one ever regrets the decision.

Related Articles

Deliberate Application Testing in Agile with Dan North

Testing in an Agile Environment

WebRTC and Its Impact on Testing

Speak Your Mind

*