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
|
EAN: 2147483647
Pages: 126