Software Engineering
Home Planning Requirements Writing Hazard Analysis Requirement Analysis Config Control Software Design Software Testing Software Standards Basic Logic

Software Testing - Reducing Risks in Test Coverage

Independent Testing

SQA surveys of programmers show that the typical programmer believes he or she has attained 80% to 90% coverage of possible test cases. However, independent checking shows that test case coverage is more like 40%. Therefore: the programmers’ own assessment of test coverage is not a reliable measure.

Bill Hetzel, Software Quality Engineering

Risk Based Testing

Time is a limited commodity in any project. Since no software can be exhaustively tested, a risk-based approach can be used to minimize the adverse impact to the user. Risk based test design generates tests in the following priority:

  1. Conditions that can produce safety hazards. Verify correct system behavior by attempting to create all risks and observing the results.
  2. Other abnormal conditions where bad data is produced (not safety related). Verify correct system behavior by inserting faults and observing the results.
  3. Normal functionality per the System Requirements. Try to use the system normally.

A risk based approach includes a product based philosophy, so that actual defects (Type I errors) will be minimized. Those Type I errors that may slip through are less likely to have an adverse affect on the user, and any adverse effects will likely be limited to minor loss of functionality, instead of producing a safety hazard.

Points to Remember:
All we can ever know for certain is that something is not working right (an anomaly exists).

And, when the system appears to work correctly, we can only have a level of confidence that it is actually working correctly.