Organization of the Guided Inspection Activity


Basic Roles

In the guided inspection activity there are three key roles that must be assumed by the available personnel.

  1. Domain expert The people in this role are the source of truth (or at least expected results). They define the expected system response for a specific input scenario. In many domains, the experienced developers are experts in their domain. They can provide a first line of validation. However, an additional, outside source of expertise is usually essential to the inspection process.

  2. Tester The people in this role conduct the analysis necessary to select effective test cases. Testers are often the creators of the basis model. When the scope of the inspection is at a system-wide level, the test case writers are often the system test team. They construct the input scenario specialized from the preconditions of a use case, the test actions as taken from the scenario, alternate paths, or exceptions sections of the use case, and the expected result as defined by the domain expert.

  3. Developer The creators of the MUT perform the role of "developer." They provide information that is not captured in the model. Except for those projects that generate code directly from a model, most developers leave many details out of the models, thus the necessary information is only available from the developers. The development staff walks the inspectors through the model, tracing actions on diagrams, showing the relationships between diagrams, and providing the actual system response at a level appropriate to the current maturity of the development.

Individual Inspection

Guided inspection begins with a desk check like traditional inspection techniques. Each tester completes a checklist specific to the type of model being inspected. Certain incompleteness and inconsistency faults can easily be found during this task. This also turns out to be the easiest task to automate. A number of tools offer some limited amount of static checks, which are basically syntactic. We have had success in expanding that capability with the scripting languages in some of the design environments. We won't name names since the landscape changes almost daily, but check out this feature as part of your next tool purchase evaluation.



A Practical Guide to Testing Object-Oriented Software
A Practical Guide to Testing Object-Oriented Software
ISBN: 0201325640
EAN: 2147483647
Year: 2005
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net