White Box vs Black Box: A False Tradeoff

A quick recap:

• White box testing is when a developer writes tests to check his or her own code. It verifies that specific parts of the product work as expected, and that any changes don’t negatively impact those basic functions.
• Black box testing is when a person who is unfamiliar with the software’s development checks functions and features of a product. It’s more open-ended and even though the tester probably gets briefed on what to test, how they get there is up to them and depends on their mindset and experience

You probably see where we’re going with this: even if you have 100% code-coverage and a massive set of unit tests, these won't let you know that users and potential customers can’t find the "Buy Now" button, that your CSS layout explodes in a rotated iPad2, or that users expect the download link to download an image and not a word document. Does that mean you should pick black box testing only?

These two approaches are complementary: your software engineers should definitely be practicing good development habits with unit, integration, and regression tests. Black box testing isn’t a substitute for these. But having human testers doesn’t absolve your team from having to write their own tests either.

In the grand scheme of things, black box testing is often neglected. Product managers are under pressure to ship fast and ship often. Programmers make the mistake of thinking: “All my unit tests are green, this software must do what it should.”

In the end, only real, unbiased testers can tell you if your software is good or not. If you want to save time, effort, and money - make sure both black box and white box testing are integral parts of your development process.