BTT 310: SW Testing & Inspection: Chapter 04: Inspections
BTT 310: SW Testing & Inspection: Chapter 04: Inspections
SW TESTING &
INSPECTION
Chapter 04: Inspections
Definitions
Manual quality assurance in three variants:
Review through sending documents to the review
team members
Fast, cheap, flexible, low performance
Structured walkthrough
Medium use of resources and moderate performance
Fagan inspection
Expensive and time consuming, but efficient and
effective
Definition: Review
Review here refers to methods which are no formal inspection, partially
review is used in the literature as a generic term for all manual test methods
(formal inspection included)
Often not only focused on the efficient detection of faults, but also as a means
for:
decision making
exchange of information
brainstorming
Normally no formal procedure exists for the execution and the choice of the
participants as well as their roles
Often no record and analysis of review data
Often no quantitative objectives
Definition: Software Inspection
Software inspection
Manual quality control of a product
Small group of participants with defined roles
Aims at the detection of faults, not at finding the solutions
Requires a functioning development process
Reader
Leads the inspection team through the session
work
Inspection Team
Recorder
Notes and classifies all faults and supports the moderator with the
Planning
other positions
The used technology is new
etc.
is then put into the change request system to be dealt with later
The author gives the revised version of the product to the moderator,
if the product was conditionally accepted in the inspection meeting
or a re-inspection is necessary
If the product was accepted, this phase is completed. The product is
brought under configuration control
Inspection Phase: Follow-Up
If the product was conditionally accepted during
the inspection meeting the verification can be done,
e.g., by the author and the reader alone.
If a reinspection was decided, a conventional
inspection meeting takes place that is focused on
the faults.
Inspection reports are to be made.
Inspection checklists
Checklist of common errors should be used to drive
the inspection.
Error checklists are programming language
dependent and reflect the characteristic errors that
are likely to arise in the language.
In general, the 'weaker' the type checking, the
larger the checklist.
Examples: Initialisation, Constant naming, loop
termination, array bounds, etc.
Inspection checks 1
Data faults • Are all program variables initialised before their values are used?
• Have all constants been named?
• Should the upper bound of arrays be equal to the size of the array or Size -1?
• If character strings are used, is a delimiter explicitly assigned?
• Is there any possibility of buffer overflow?
Storage management • If a linked structure is modified, have all links been correctly
faults reassigned?
• If dynamic storage is used, has space been allocated correctly?
• Is space explicitly de-allocated after it is no longer required?
Exception • Have all possible error conditions been taken into account?
management faults
Reference: Ian 8ed
Inspection rate
Techniques
3 Golden rules:
1. Use walkthrough for training
2. Use inspections to improve the quality of the
work product and its process
3. Use Desk Check for individual review