Verification:

1
Verification vs validation

• Verification
• Are we building the product right?
• The software should conform to its specification.
• Validation
• Are we building the right product?
• The software should do what the user really needs
  / wants.

2
VV goals

• Verification and validation should establish
  confidence that the software is fit for
  purpose.
• This does NOT usually mean that the software must
  be completely free of defects.
• The level of confidence required depends on at
  least three factors

3
Factors affecting level of confidence required

• Software function / purpose Safety-critical
  systems require a much higher level of confidence
  than demonstration-of-concept prototypes.
• User expectations Users may tolerate
  shortcomings when the benefits of use are high.
• Marketing environment Getting a product to
  market early may be more important than finding
  additional defects.

4
Static and dynamic VV

• Software inspections / reviews analyze static
  system representations such as requirements,
  design, source code, etc. (static V V)
• Software testing executing an implemen-tation of
  the software to examine outputs and operational
  behavior (dynamic V V)

5
Inspections and testing are complementary

• Inspections can be used early with non-executable
  entities and with source code at the module and
  component levels.
• Testing can validate dynamic behaviour and is
  the only effective technique at the sub-system
  and system code levels.
• Inspections cannot directly check non-functional
  requirements such as performance, usability, etc.

6
Program inspections / reviews

• Formalised approach to document walk-throughs or
  desk-checking.
• Intended exclusively for defect DETEC-TION (not
  correction).
• Defects may be logical errors, anomalies in the
  code that might indicate an erroneous condition,
  or non-compliance with standards.

7
Inspection pre-conditions (entry criteria)

• A precise specification must be available.
• Team members must be familiar with the
  organization standards.
• Syntactically correct code must be available (for
  code inspections).

8
Inspection pre-conditions

• An error checklist should be prepared.
• Management must accept the fact that inspection
  will increase costs early in the software
  process. (payoff comes later)
• Management must not use inspec-tions results for
  staff appraisals. (Dont kill the goose that lays
  the golden eggs.)

9
Inspection procedure

• System overview presented to inspection team.
• Code and associated documents are distributed to
  inspection team in advance.
• Inspection takes place and discovered errors are
  noted.
• Modifications are made to repair discovered
  errors (by owner).
• Re-inspection may or may not be required.

10
Inspection teams

• Typically made up of 4-7 members.
• Author (owner) of the element being inspected.
• Inspectors who find errors, omissions and
  inconsistencies.
• Reader who steps through the element being
  reviewed with the team.
• Moderator who chairs the meeting and notes
  discovered errors.
• Other roles are Scribe and Chief moderator

11
Inspection checks