Black Box Testing

Black box testing is testing that occurs from the viewpoint of an end user. Black box tests find bugs such as incorrect functions, interface problems, and database errors.

Black box tests are also the only form of test the customer is likely to understand; mention "basis path testing" to a banker, and you'll have him frowning. Therefore, black box testing is absolutely mandatory for acceptance testing. The customer must be able to understand these tests, so that he/she will know for sure whether or not you've met the contract requirements.

Required minimum: at least one black box test per customer requirement.

Equivalence classes: This is a subset of black box testing, but important in its own right. Most programs divide input into categories, or classes: a tax program may place a paycheck below $500 in one tax bracket, a check from $500 to $1000 in another bracket, and a check for more than $1000 in yet a third bracket. Each of these three brackets takes the program in a different direction, so you MUST test all three directions at least once.

Boundary testing: The boundaries between equivalence classes are favorite places for bugs to congregate. You should give special attention to the edge of each class--and, if possible, try to go beyond the edge by entering illegal values (such as -$1).

White Box Testing