Testing Models for Additional Qualities

Increasingly, projects are chartered to achieve more aggressive objectives such as the development of extensible designs, the design of reusable frameworks, or highly portable systems. The products of the analysis and design phases of these projects are most critical for achieving these types of objectives. In particular, the architecture is key to the success. Guided inspection can be used to ask metalevel questions about the system. In this mode, the test scenarios are developer actions on the system and not user actions. Instead of asking how the objects in the system would interact, the question is, "How must the classes of the system be changed to provide the newly required behavior?"

The changes to the design or the revisions needed to produce a framework from an existing application can be captured as change cases [EcDe96]. A change case is a use case that is not a requirement of the system, but it is an anticipated change to the system. Guided inspection applies correctness, completeness, and consistency criteria to the current analysis and design models with the change cases as the source of test scenarios.

For example, if the project is to build a framework upon which future development will be based, it is not sufficient to test against the current uses for the system. Consider the change case shown in Figure 4.37. Test cases can give insight into the effort required to extend the framework by testing how complete the existing model is relative to the new requirements. The second change case, as shown in Figure 4.38, could be used to test the architecture. It would be used to determine how completely the existing architecture covers the new requirement.

Figure 4.37. A change case for Brickles

Figure 4.38. A second change case

The technique for testing these objectives can be viewed as a series of steps. Each of the steps is described and accompanied by an example.

• Explicitly state the objective that the change case will address.

  The design will be easily extensible to accommodate new games.

• Construct a "change case" including a specific scenario that illustrates the objective.

  The framework is to be used to implement pinball games that are user configurable. The obstacles to be available include posts, flippers, and bumpers.

• Create test cases by sampling from the range permitted by the change case.

  A pinball game is to be created. Figure 4.39 illustrates two new states that might be added to the Brickles state machine.

  Figure 4.39. A state diagram for a pinball game

  

• Enumerate the work needed to achieve the objective by specifying the differences in state and behavior required for the new objective. This can be accomplished by identifying the new subclasses that must be defined.

  The StationarySprite class will be subclassed to provide the new obstacles. A Ball class will extend MovableSprite and CollideWithBall methods would be required for all sprites. Attributes will be added to give a specific point value to each obstacle. The PinBall subclass of ArcadeGame would add a Score attribute.

• Evaluate the current design relative to the design required to achieve the objective. Answer the following questions: "Are there fundamental concepts missing that would have to be added?" and "Are there contradictions between what exists and what would be added?"

  The necessary base classes and methods are present. The needed attributes can be added without conflict with existing attributes. However, the Sprite class must be modified.

• Repeat with additional test scenarios until all proposed changes are examined.

The output of this process is a set of potential changes needed to achieve the desired system quality, such as extensibility. The inspection searches for missing concepts and contradictions between what exists in the model currently and what would need to be added to the model in order to achieve the new objective. This technique can provide early feedback to the development team about fundamental weaknesses in the design.