Software reviews are a "filter" for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors and defects that can then be removed.

Software reviews "purify" the software engineering activities that we have called analysis, design, and coding. Freedman and Weinberg discuss the need for reviews this way:

Technical work needs reviewing for the same reason that pencils need erasers: To err is human. The second reason we need technical reviews is that although people are good at catching some of their own errors, large classes of errors escape the originator more easily than they escape anyone else. The review process is, therefore, the answer to the prayer of Robert Burns:

O wad some power the giftie give us to see ourselves as other see us

A review—any review—is a way of using the diversity of a group of people to:

1. Point out needed improvements in the product of a single person or team;

2. Confirm those parts of a product in which improvement is either not desired or not needed;

3. Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable.

Many different types of reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the coffee machine is a forma review, if technical problems are discussed. A formal presentation of software design to an audience of customers, management, and technical staff is also a form of review.

A formal technical review is the most effective filter from a quality assurance standpoint. Conducted by software engineers (and others) for software engineers, the FTR is an effective means for improving software quality.

Cost Impact of Software Defects

The IEEE Standard Dictionary of Electrical and Electronics Terms (IEEE Standard 100-1992) defines a defect as "a product anomaly." The definition for fault in the hardware context can be found in IEEE Standard 610.12-1990:

(a) A defect in a hardware device or component; for example, a short circuit or broken wire, (b) An incorrect step, process, or data definition in a computer program. Note: This definition is used primarily by the fault tolerance discipline. In common usage, the terms "error" and "bug" are used to express this meaning. See also: data-sensitive fault; program-sensitive fault; equivalent faults; fault masking; intermittent fault.

Within the context of the software process, the terms defect and fault are synonymous. Both imply a quality problem that is discovered after the software has been released to end-users (or to another activity in the software process).

The primary objective of formal technical reviews is to find errors during the process so that they do not become defects after release of the software. The obvious benefit of formal technical reviews is the early discovery of errors so that they do not propagate to the next step in the software proess.

RELATED POST

BACK GROUND ISSUES IN SOFTWARE TESTING

Related Posts

Compliance Testing technique Recovery testing technique Execution testing Structural software testing Static and dynamic testing Functional and structural testing Testing verification and validation Test Process Independent Software Testing and part two Testing metrics and Life cycle testing c programming break statement V model Software Testing Security Testing Technique

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing
Complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .