Divide and Conquer

Software systems typically involve connections between several code modules residing in various components that communicate with each other to accomplish user-selected functions. The following illustration, Figure 12.5, is a partial system map for a single menu option from the director's three-bullet foil. The code modules reside in various hardware components and communicate across networks, as shown in the illustration. When a user selects the menu option, the system interacts across network-based components in order to perform the function.

Figure 12.5: A three-dimensional representation of the internal paths in the director's three-bullet foil.

Testers routinely cross boundaries between different types of modules and system components to follow logical function paths of interest. These boundaries can be ignored or examined in detail. When there is an undesirable or unusual response from the system, testers routinely divide the test effort along these boundaries to verify input and output across these boundaries. When the flow between such boundaries is tested specifically and exhaustively, it is normally called integration testing.

The strategy in integration testing is to send application requests between the components and then verify and validate the result. If the output of one component is not acceptable to the component receiving it, a deeper investigation is conducted to determine which component is not performing according to the specification. This approach to problem solving by decomposing the system into smaller and smaller components is called divide and conquer.

The total number of tests conducted is the sum of all the tests in all the components. The test planning process will identify tests in many components, as is indicated in Figure 12.5.