Within the context of the software development, the terms defect and fault are synonymous. Both imply a problem that is discovered after the software has been released to end users.
The book makes a distinction between error – a problem found before being released to the end user and defect or fault. However, in the real world, this distinction is not always made.
There are several places one can perform reviews to reduce the number of problems/bugs that get released to the end user. With each set of test (unit, integration, etc) you hope to catch 50% or more of the problems and fix them. Problems that are passed through can hide other bugs, or cause non-issues to appear to be an issue.
Technical reviews are one of many actions that are required as part of good software engineering practice. However, since there are only so many hours, you need to know what types of reviews are going to provide the best results.
- Preparation effort, Ep—the effort (in person-hours) required to review a work product prior to the actual review meeting
- Assessment effort, Ea— the effort (in person-hours) that is expended during the actual review
- Rework effort, Er— the effort (in person-hours) that is dedicated to the correction of those errors uncovered during the review
- Work product size, WPS—a measure of the size of the work product that has been reviewed (e.g., the number of UML models, or the number of document pages, or the number of lines of code)
- Minor errors found, Errminor—the number of errors found that can be categorized as minor (requiring less than some prespecified effort to correct)
- Major errors found, Errmajor—the number of errors found that can be categorized as major (requiring more than some prespecified effort to correct)
Reviews can fall under the informal, or casual, to a more formal and rigorous methodology. The more serious the situation and responsibility of the software, the more rigorous and detailed a review needs to be.
Consider a simple mobile game, like one of the millions where pop a collection of balloons to get a score. No one’s life depends on it, and if the high score is not 100% accurate, most people wouldn’t know.
Now consider you’re writing the software to control a defibrillator machine. Little mistakes can have costly repercussions, so you need to test and verify every little step.
Review Techniques was originally found on Access 2 Learn
