A Practical Guide to Testing Object-Oriented Software

• Want to learn how to inspect the semantics of UML models? See The Basics of Guided Inspection.

• Need to set up an inspection session? See Organization of the Guided Inspection Activity.

• Need a technique for testing a model for extensibility? See Testing Models for Additional Qualities.

Developers model the software they are constructing because it assists in understanding the problem they are solving and because it helps manage the complexity of the system being developed. The models of analysis and design information will eventually be used to guide the implementation activities of the project. If the models are of high quality, they make a valuable contribution to the project, but if they contain faults, they are equally detrimental. In this chapter we present guided inspection, an enhanced inspection technique for verifying the models as they are created and for validating the completed models against project requirements. The principal shortcoming of standard review techniques is that they focus primarily on what is there (in the model) rather than what should be there. Reviews do not provide a means for systematically searching for omissions from products. Even Fagan inspections [Faga86], which use checklists to make the process more detailed, do not provide a means for determining what is missing from a model.

Guided inspection applies the testing perspective very early in the development process. Traditionally, testing has begun at the unit implementation level and has continued as code segments are integrated into larger pieces until the entire system is available to be tested. In this chapter, we will begin "system testing" when the "system" is still represented only as analysis or design information. A new version of the traditional "V" testing model, shown in Figure 4.1, relates the repeated applications of guided inspections to the various levels of testing.

Guided inspection requires valuable resources, and the time and attention of project personnel. So is it worthwhile? Studies have reported widely varying savings ratios for finding and repairing faults early in the development process as opposed to during the compilation or system test phases. For example, repairing a fault found at system test time may cost as much as one hundred times the cost of repairing the same fault during analysis. So even a moderate effort at testing the models can result in big savings.