From the white paper:
A review is an examination of some aspect of the software development process. More specifically, it is an examination of some deliverable: a design, a test plan, source code, and so on. Preliminary reviews may work from overheads or even whiteboard diagrams, but reviews that are more formal should work from hardcopy documents distributed well in advance of the review.
Reviews serve three important purposes in software development. First, they help to align development efforts. An hour of live discussion about a given deliverable can clarify more than any number of e-mails, memos, and documents.
Second, reviews help to raise issues, find problems, and identify risks. The simple act of having to present a deliverable for review will usually lead those involved to examine it more closely. At the same time, others examining that deliverable may see things or raise questions that escaped those more directly involved.
Third, reviews help to establish conformance to guidelines and standards. Such conformance aids completeness and correctness of the deliverable. It also makes it easier for others to examine and work with the deliverables.
Well-run reviews are one of the most effective activities in software quality assurance. They are usually better at finding defects than testing, while costing less. At the same time, you must carefully adjust the frequency of reviews. Too few reviews will result in far more effort spent in other QA activities (e.g., testing); too many reviews will interfere with and slow the development cycle.
There are several kinds of reviews, differing in preparation and complexity. The four discussed here, listed in order of increasing formality, are self-reviews, informal reviews, structured walkthroughs, and inspections