An Overview

Let's look at a quick example of using the guided inspection technique. To set the stage, we are in the initial stages of developing Brickles. The team has produced the design-level class diagram shown in Figure 2.18 and other diagrams such as the state diagram shown in Figure 2.19 and the sequence diagram shown in Figure 2.20. We are about to begin coding but want to validate the design model before spending extensive time coding the wrong definitions.

We begin by assigning the inspection team. The team includes the two of us who developed the model, a system tester from our company and our company's process person who will be the moderator. The tester will develop a set of test cases from the use case diagram. We developers will show how the classes in the design model handle each test case. The moderator will define the inspection boundaries, schedule the guided inspection session, distribute materials, keep the session moving forward, and then complete the final report.

In preparation for the session, the moderator defines the boundaries of the inspection by identifying the scope and depth of the information to be inspected. The scope is defined by a set of use cases. In our case, the scope covers all the use cases and thus the complete application. The depth is defined by identifying levels of containment in the composition hierarchies. In the case of Brickles, we will not inspect the objects that are aggregated within the BricklesView object. We will focus instead on those that represent the state of the match at any given time in a BricklesDoc object.

The tester writes test cases using the use cases found in Figure 2.11. We will focus on one test case, shown in Figure 4.2. Before the meeting, the developers complete the Design Model checklist shown in Figure 4.3. This exercise is completed individually by each developer. It requires that the developer compare the class diagram from the analysis model, shown in Figure 2.13, with the class diagram in the design model. Finally, the moderator sends out notice of the meeting along with either paper copies of the model or a URL to the Web version.

Figure 4.2. Test case #1

Figure 4.3. Example design phase checklist

The test report from the guided inspection section notes the problems found during the symbolic execution of the test cases. With regards to the test case being considered here, the design is considered to have failed the test. The test report would reflect that it was not possible to determine how to complete the symbolic execution at this point in the algorithm. We do not want to confuse testing and debugging, but since we know exactly where execution terminated, it should be reported. The test report also includes the sequence diagram used to record the test execution, as shown in Figure 4.4.

Figure 4.4. Partial sequence diagram for test case #1

A Portion of a Session Transcript

Melissa (moderator): OK, let's get started. Everyone has had a chance to look at the model and Dave and John have completed the checklists. Let me remind everyone that we are focusing on the locally designed classes and will ignore the standard user-interface classes such as menus. So let's begin with the first test case, Jason.

Jason (tester): Here is the first case [he hands out the first test case]. With John's help, I've laid out the beginnings of a sequence diagram for this test case based on the test case preconditions [see Figure 4.4]. So, the player selects Quit from the menu and…

John (developer): My :BricklesView would receive the Quit message. And my object would send the Quit message to Dave's aBricklesDoc. [He draws these onto the sequence diagram.]

Dave (developer): When :BricklesDoc gets the Quit message it will send the Stop message to aTimer. [He begins to draw this on the sequence diagram.]

Jason: Wait a minute! As I read the class diagram there is no association between those two classes.

Dave: John, where is that Stop message supposed to go? I thought you said you were going to implement that method.

John: [Busy shuffling between the sequence diagram and the class diagram with a confused look on his face.] Defect!

Melissa: Sounds like we are ready for the next test case.