Functional Test Data Design

We believe that it is important that test design engineers have a basic knowledge of test case design techniques. If you are already familiar with these techniques and do not need to review them, skip to the beginning of the next chapter. If this is your first exposure to them, you will want to read this overview and review Myers (16) and Mosley (15), which contain detailed examples of how the techniques are used.

Black Box (Requirements-Based) Approaches

Cause-Effect Graphing

This approach involves identifying specific causes and effects that are outlined in the requirements document. Causes are conditions that exist in the system and account for specific system behaviors known as effects. Effects can be states that exist temporarily during the processing or system outputs that are the result of the processing. The causes and effects are transformed into a cause-effect diagram that can be used to create test cases.

Equivalence Partitioning

This approach uses the system requirements to identify different types of system inputs (input domains). Each input type is defined as an Equivalence Class. Rules are derived to govern each Equivalence Class. The rules are used as a basis for creating test cases.

Boundary Analysis

This approach strives to identify Boundary Conditions for each equivalence class. The conditions are used to create test cases containing input values that are on, above, and below the edges of each equivalence class.

Error Guessing

This approach uses the tester's experience and intuition to plug any gaps in the test data developed with the other approaches.

Gray Box (Both Requirements- and Code-Based) Approaches

Decision Logic Tables

This approach looks at combinations of equivalence classes. It can be used to develop test cases from any portion of the requirements containing complex decision logic structures that would result in If/Then/Else logic in the system processing.

White Box (Code-Based) Approaches

Basis Testing

This approach designs test cases that exercise all control flow paths through each program module. It addresses control flow as it occurs due to branching within the module. In Visual Basic, branching is the result of If/Then/Else/Endif statements, GoTo statements, For/Next loops, While/When loops, and Select Case statements. Source code listings or program flowcharts are used to identify the branch points in each module, and this information is used to construct Control Flow Diagrams that are used to design the test cases.

The objective is to test the basis set of logic paths. The basis set consists of a set of control paths that have path elements common to all of the paths through the module. The total set of module paths can be constructed by disassembling the basis paths and reassembling them in different combinations. Each different combination accounts for one of the module's logic paths.

Each module has a finite number of unique logic paths; however, the number may be quite high. The philosophy in testing only the basis paths is that, if the building blocks that are common to all paths are tested, it is not necessary to test all of the module's logic paths. This results in a significant savings in the number of test cases needed to test each module.