Moderator responsibilities (at the beginning of the inspection)

¦¦ Introduce participants and identify roles.

¦¦ Restate the objective of the inspection.
¦¦ Verify inspectors readiness by checking time spent in preparation and
whether all material was reviewed prior to the meeting (as indicated on
each inspector s inspection preparation report). If any of the participants
are not prepared, the moderator must decide whether to continue with the
inspection or reschedule it to allow for further preparation.
Reader responsibilities
¦¦ Read or paraphrase the material.
Inspector responsibilities
¦¦ Discuss potential defects and reach a consensus about whether the defects
actually exist.
Recorder responsibilities
¦¦ Record defects found, by origin, type, class, and severity, on the inspection
defect list.
¦¦ Classify each defect found, with concurrence from all inspectors.
¦¦ Prepare the inspection defect summary (see Work Paper 8-15).
¦¦ Author responsibilities
¦¦ Clarify the product, as necessary.
Moderator responsibilities (at the end of the inspection)
¦¦ Call the inspection to an end if a number of defects are found early, indicat-
ing that the product is not ready for inspection. The author then is responsi-
ble for reinitiating an inspection, through the moderator, once the product
is ready.
¦¦ Determine the disposition of the inspection and any necessary follow-up
work.
¦¦ Approve the inspection defect list and the inspection summary, and then
forward copies to the author and quality assurance personnel.
¦¦ Sign off on the inspection certification report if no defects were found (see
Work Paper 8-16).

Planning can be one of the most challenging aspects of the software testing proc
ess.
The following guidelines can make the job a little easier:
1. Start early. Even though you might not have all the details at hand, you can
complete a great deal of the planning by starting on the general and working
toward the specific. By starting early, you can also identify resource needs and
plan for them before they are subsumed by other areas of the project.
2. Keep the test plan flexible. Make it easy to add test cases, test data, and s
o on.
The test plan itself should be changeable, but subject to change control.
3. Review the test plan frequently. Other people s observations and input greatly
facilitate achieving a comprehensive test plan. The test plan should be subject
to quality control just like any other project deliverable.
4. Keep the test plan concise and readable. The test plan does not need to be
large and complicated. In fact, the more concise and readable it is, the more
useful it will be. Remember, the test plan is intended to be a communication
document. The details should be kept in a separate reference document.
5. Calculate the planning effort. You can count on roughly one-third of the test
-
ing effort being spent on planning, execution, and evaluation, respectively.
6. Spend the time to develop a complete test plan. The better the test plan, the
easier it will be to execute the tests.