These are both testing methodologies. Both are important to understand and it is not a matter of choosing either White Box Testing or Black Box Testing. Generally speaking a Black Box Testing approach would be the most widely used with White Box Testing being used for some specific tasks that require special testing scrutiny.

White Box Testing

White box testing requires a developer examining code before deciding on how to write the test. It therefore requires an in-depth knowledge of how the software is implemented. The developer then defines test cases that cover as much code as possible. Another way of putting this is - it is what black box testing and TDD is not.

All white box testing techniques are tightly coupled to the implementation. The author of the code under test usually implements the white box tests.

White box testing techniques usually focus on code coverage, taking into account statements, decisions/branches, condition testing or path testing.

In this whole process the specification/requirements do not necessarily play a role. White box testing tries to maximize the amount of code that is tested, but it doesn’t necessarily validate if the tested code meets the actual requirements definition.

Furthermore the tight coupling between code and white box tests causes tests to be fragile. Fragile tests tend to cause false positives when refactoring code.

Black Box Testing

Black Box Testing get its name from the way it views the software as a black box with inputs and and an output. A tester need have no knowledge of how the code is written inside the box.

The test is derived solely from the specification/requirements, which is why black box testing is also called specification testing. It forces the tester to concentrate on what the software does, not how it does it.

Because black box testing techniques require no knowledge of the systems implementation, testing and implementation can be done by separate people. In some cases the tester doesn’t even have to have programming knowledge.

The most widespread black box testing techniques are equivalence class partitioning, boundary value analysis, state transition tables and decision table testing.

With black box testing we don’t know if all code is tested, but we can make sure, that it absolutely meets the requirements.

Which is better?

As with most things, it’s a case of “different horses for different courses”. There are some cases where you should definitely use white box testing. It is a good technique for things that are prone to security issues as well as critical areas of the code that you feel need an extra level of testing.

But we would strongly suggest you use black box testing wherever you can. For most application types, this means “95% of the time”.

Some of the advantages of black box testing are :

  • The developer can share or even shift the responsibility of requirements specification to other people such as POs, QA Engineers and Domain Experts.

  • If you are implementing TDD then you are black box testing by definition.

  • Especially using tools like DevMate, the developer can spend more time writing functional code rather than test code.

  • You may not necessarily get perfect code coverage (please see “Obsessed with Code Coverage?”) but you will get better quality.

  • You will be a lot more productive and efficient in your ability to write quality tests across an entire application.