Great software performs well on two levels. It does exactly what you want it to do with no mistakes or confusion. Second, the code behind it is simple, clean, and safe. All the stuff behind the scenes--that the user doesn’t see--works properly and doesn’t have loopholes or loose ends. When we test software, we test for both process and outcome. We call these two assessments white box and black box testing.
White box testing is also sometimes called clear box testing. You can look inside and see how the code works. When we perform a white box test, we’re checking to make sure all the internal workings of the software are complete and secure.
On the other hand, black box testing doesn’t allow the tester to look inside the code. Instead, it only deals with whether the software produces the correct results from given inputs and includes all the functionality that the client requested. With black box testing, we only care about getting the right outcomes.
It’s easy to think of these two testing regimes as opposed to one another, but they’re not. They test software from different angles, and they’re both essential to creating and releasing a great application. Let’s take a closer look at how they work.
As we’ve already seen, black box testing cares only about results and functionality. The testers know what the software should do, but they don’t know how it does it. They won’t have access to the code, and they can only judge the test based on whether the software produces the right results.
The key question for black box testers is, “Does this application work as expected?” If yes, then the software passes the test. If not, then the software’s design has failed to account for something, and it needs to be rethought.
How It Works
A test designer will put together a list of inputs to try. Some of these inputs are valid, and should produce a certain outcome. Other inputs will be invalid, and they should produce an error or prompt of some type. The test designer will often use a test oracle or previous test results to help determine what future tests to try.
Advantages & Drawbacks
The biggest advantage of a black box test is it separates the user and developer perspectives. It focuses on whether or not the software produces the desired result for the end user. As a result, it’s also useful for identifying missing functionality or modules that have been left out of the design, perhaps by omission, mistake, or oversight.
However, since black box tests don’t dig into the code, they’ll only realize a fraction of the potential test scenarios. This lack of knowledge about the internal workings of the software also means black box tests can be inefficient, since much of the time the tester is simply guessing about new test vectors.
Developers conduct white box tests, because they need to understand the code before they test it. It’s possible an outside testing service could learn the code base and perform the tests, but most likely the developer who created the software will run the test.
Since they know how the code works, developers will also know what to test for. They’re explicitly looking for ways to throw off the processes in the code in front of them (e.g. throwing exceptions). Many developers think of software unit testing when they think of white box, but it can also include integration and systems-level tests as well.
How It Works
The key to white box is careful inspection and testing of the source code to prevent hidden errors from popping up later on. The tester will take the time to understand the source code, conduct a risk analysis, and design a testing regime that pushes the limits of the code’s risk factors.
Advantages & Drawbacks
White box testing is efficient in finding issues, especially if a seasoned developer is conducting the review of the source code. These tests also have more thorough coverage than black box tests because they can see the underlying and hidden errors. White box tests are also helpful for code optimization, even if the software performs properly.
The drawbacks of white box have to do with functionality from a user perspective. A piece of software may be perfectly coded, but it may be missing a key feature that a user needs. These tests are also more expert-intensive. You need high-level knowledge of development and the source code in question before you can conduct the test.
White & Black Box Testing, Combined
The ideal scenario is one where software undergoes both white and black box testing. This ensures you have clean source code that also produces the desired results and functionality for the end user. Increasingly, the lines between white and black box testing are blurring in modern development. Gray-box testing, with limited knowledge of the code architecture, and other hybrid testing structures are becoming popular as testing demands change. Ultimately, a great piece of software needs to be solid in both form and function in order to be useful and secure.