The Art of Software Testing, Second Edition

5.4. Performing the Test

The remaining part of the module test is the act of actually carrying out the test. A set of hints and guidelines for doing this are described here.

When a test case produces a situation where the module's actual results do not match the expected results, there are two possible explanations: either the module contains an error or the expected results are incorrect (the test case is incorrect). To minimize this confusion, the set of test cases should be reviewed or inspected before the test is performed (that is, the test cases should be tested).

The use of automated test tools can minimize part of the drudgery of the testing process. For instance, there exist test tools that eliminate the need for driver modules. Flow-analysis tools enumerate the paths through a program, find statements that can never be executed ("unreachable" code), and find instances where a variable is used before it is assigned a value.

It is helpful, when preparing for a module test, to review the psychological and economic principles discussed in Chapter 2. As was the practice earlier in this chapter, remember that a definition of the expected result is a necessary part of a test case. When executing a test, remember to look for side effects (instances where a module does something it is not supposed to do). In general, these situations are difficult to detect, but some instances may be found by checking, after execution of the test case, the inputs to the module that are not supposed ...