Review, Static analysis and Dynamic testing are the different testing techniques used to find different types of defects effectively and efficiently. Static techniques find causes of defects whereas dynamic testing finds the failure itself.

Review is a way of static testing technique done before dynamic testing.Review is manual examination of software work product (including code) without execution of software and make comments about it. Review is mostly a manual activity but there is some tool support also.
Review can be performed on any of the software works like requirement specification, design specification, code, test plans, test specification, test cases, test scripts, user guides or web pages.
Typical defects that are easier to find in review than in dynamic testing are deviation from standards, requirement defects, design defects, insufficient maintainability and incorrect interface specifications.

Advantages of Review
Early defect detection and correction – It is much cheaper to remove errors when found during review than finding errors by running tests on execution code.
Development productivity improvements and reduced development timescales
Reduced testing cost and time
Lifetime cost reduction
Fewer defects and improved communication
Can find Omissions ( eg. in requirements, which are likely to be found in dynamic testing

Review Process

Types of Reviews vary from informal (no written instructions for the reviewer) to systematic (includes team participation, documented results of the review and documented procedures for conducting the review) and formality of a review process depends on factors such as maturity of the development process, any legal or regulatory requirements or need for an audit trail.
The way a review is carried out depends on the agreed objectives of the review like find defects, gain understanding, educate testers and new team members.

Activities of a Formal Review

1. Planning
Defining the review criteria
Selecting the personnel
Assigning roles
2. Defining the entry and exit criteria for more formal reviews (eg inspections)
Selecting which part of the document to review.
3. Kick-off
Distributing documents
Explaining the objectives and process to the participants.
4. Checking the entry criteria
5. Individual preparation
Preparing for the review meeting by reviewing the documents
6. Noting down the questions and comments
7. Examination/Evaluation/Recording of results (review meeting)
Discussing or logging the documented results or minutes
Noting, making recommendation and decision regarding handling defects
8. Rework
9. Fixing defects found (by author)
Recording updated status of defects
10. Follow up
Checking that defects have been addressed
Gathering metrics
11. Checking on exit criteria
Checking that defects have been addressed
Gathering metrics

Roles and Responsibilities

Manager :
Decides on the execution of review
Allocates time in the project schedules
Determines if the review objectives are met
Moderator :
Leads the review of the document
Plans the review, running meeting and follow up after meeting
success of the review depends
Author :
chief responsible for the document
Reviewer/Checker/Inspector :
individuals with specific technical or business background
Identify and Describe defects/findings
Participates in review meeting
Scribe/Recorder :
Documents all the issues, problems and open points in the meeting

Types of Reviews
Informal Review
No formal process
May take the form of pair programming or a technical lead reviewing design and code
Results may be documented
Varies in usefulness depending on the reviewers
Main purpose: some benefit with no cost
Walk through
Meeting led by author
May take the form of scenarios, dry runs, peer group participation
open-ended sessions
Optional pre-meeting preparation of reviewers
Optional preparation of the review
Optional Scribe(not the author)
May vary in practice from quite informal to very formal
Main purpose : learning, understanding, finding defects
Technical Review
Documented, defined defect detection process that includes peers and technical experts with optional management participation
May be performed as a peer review without management participation
Ideally led by trained moderator
Pre-meeting preparation by reviewers
Optional use of checklists
Preparation of a review report which includes the list of findings, whether the software meets its requirements, recommendations related to findings.
May be formal or informal
Main purpose : Discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations and standards
Led by trained moderator
Usually conducted as a peer examination
Defined roles
Includes metrics gathering
Formal process based on rules and checklists
Specified entry and exit criteria for acceptance of the software product
Pre-meeting preparation
Inspection report including list of findings
Formal follow-up process
Optional reader
Main purpose : finding defects
Walkthroughs, Technical reviews and Inspections can be performed within a peer group (colleagues of the same organizational level) called peer review

Static Analysis by tools

Objective : to find defects in software source code and software models.
Static analysis tools analyse program code (eg control flow and data flow) and generated ouptuts (eg html and xml)
Developers use static analysis tools for checking against predefined rules or programming standards before and during component and integration testing or by designers during software modelling.
Compliers may offer support to static analysis by calculating metrics.

early detection of defects prior to test execution
early warning about suspicious aspects of code and design
identification of defects not easily found be dynamic testing
detecting dependencies and inconsistencies in software models
improved maintainability of code and design
prevention of defects if lessons are learnt early

Typical defects discovered
Referencing a variable with an undefined value
Inconsistent interfaces between modules and components
Variables that are not used or are improperly declared
Unreachable dead codes
Missing and erroneous logic
Overly complicated constructs
Syntax and security violations
Programming standard violation


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s