Black Box Testing

Black Box Testing treats an application as a black box and only looks at the outputs that are produced by specific inputs into the application. The black box tester does not need to understand why the code does what it does, and they should not have access to the source code of the application. Requirements are used to determine the correct outputs of black box testing, and these test cases are used to validate that the right software is being built, i.e. that the application does what the requirements say.

Black box testing checks that required functionality exists and is correct, the interface works properly, data structures behind the interface work properly, the behavior and performance of the system are within proper bounds, and that the initialization and termination of the program are correct. Integration, functional and system, acceptance, beta, and regression testing all are forms of black box tests.

A minimal black box test suite should have one test case for every requirement of the application. To optimize testing beyond this minimal set of tests equivalence partitioning, boundary value analysis, decision tables, and diabolical test cases should be created. Equivalence partitioning divides the set of possible input values into equivalence classes. Only a value from each of the equivalence classes needs to be tested. Boundary value analysis looks at testing around a set boundary. A test case should be made for the boundary value, n, n-1, and n+1. Decision tables looks at all decision points in the program and looks at the results of all decision paths in the scenario. Finally, diabolic tests investigate extreme use of the application.

Author: Laurie Williams and Sarah Heckman
Maintained By: Sarah Heckman
Last Updated: 2008-08-25