Black and White

Software comes in layers.  Higher layers operate and are dependent on the layers below.  Each layer presents one or more interfaces.  We test these interfaces to their specifications.

Black Box Testing

Black box testing means testing the interfaces presented by the outermost layer, the layer operated by a user, for instance.  It typically includes testing things like GUIs and CLIs.  Accordingly, test cases are defined by the actions you can take in manipulating the interfaces (GUI or the CLI).

Black box testing of an automobile, for instance, would include test cases describing using the steering wheel, gas, and brakes.  It would not include test cases directly manipulating the alternator.

White Box Testing

White box testing means testing any of the layers below the outermost layer.  These layers are not directly manipulated by a user.  Instead, their interfaces are accessed by the other layers.  Our test cases are therefore defined by the actions taken in manipulating the interfaces they present to the other layers.  This kind of testing requires a test jig.

To continue the car metaphor, white box testing would mean testing engine parts that are under the hood.  The alternator, for example, is bench tested outside of the car.  The test jig is designed to imitate the car's connections to the alternator.  It contains structural mount points to which the alternator can be bolted, an electric motor with a rheostat (continuous speed control) and pulley to which the alternator's belt can be attached, and electric leads to an amp/voltage meter to monitor electrical output.  Test cases would include manipulating the rheostat and evaluating amp meter readings.

Understanding our product's software layers enables us to weigh the costs and benefits of black and white box testing helps us allocate our test resources to best effect.  I'll discuss the costs and benefits in a future post.


Todd Shoenfelt
http://www.linkedin.com/in/toddshoenfelt