Monday, September 26, 2011

Peer Review Testing

Peer Review: It is a kind software review in which either a document or code is examined by the author with their colleagues, to evaluate the technical content and quality.
Purpose of Peer Review: The purpose of peer review is to detecting the defects in software documents, controlling the development and testing process, monitors the things  in right direction.
Walk through: In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems.

"Software product" normally refers to some kind of technical document. As indicated by the IEEE definition, this might be a software design document or program source code, but use cases, business process definitions, test case specifications, and a variety of other technical documentation may also be walked through.

A walkthrough is normally organized and directed by the author of the technical document.
IEEE 1028[1] recommends three specialist roles in a walkthrough:
ñ                  The Author, who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items;
ñ                  The Walkthrough Leader, who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author); and
ñ                  The Recorder, who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meetings.


Software Review: A software review is "A process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".
IEEE 1028 recommends the inclusion of participants to fill the following roles:
The Decision Maker (the person for whom the technical review is conducted) determines if the review objectives have been met.
The Review Leader is responsible for performing administrative tasks relative to the review, ensuring orderly conduct, and ensuring that the review meets its objectives.
The Recorder documents anomalies, action items, decisions, and recommendations made by the review team.
Technical staff are active participants in the review and evaluation of the software product.
Management staff may participate for the purpose of identifying issues that require management resolution.
Customer or user representatives may fill roles determined by the Review Leader prior to the review.

Inspection: A Software Inspection is a formal review of a work product by the work product owner and a team of peers looking for errors, omissions, inconsistencies, and areas of confusion in the work product. A formal inspection is performed according to established procedures and schedules. A typical inspection includes the following stages: Planning, Overview Meeting (Kickoff), Preparation, Inspection Meeting, Rework, and Follow-up. A formal inspection has well-defined roles for participants, such as moderator, recorder, reader, author, See also DACS Gold Practice Formal Inspections.

During an inspection the following roles are used.
ñ                  Author: The person who created the work product being inspected.
ñ                  Moderator: This is the leader of the inspection. The moderator plans the inspection and coordinates it.
ñ                  Reader: The person reading through the documents, one item at a time. The other inspectors then point out defects.
ñ                  Recorder/Scribe: The person that documents the defects that are found during the inspection.
ñ                  Inspector: The person that examines the work product to identify possible defects.

No comments:

Post a Comment