3.Static Techniques

Phases of a formal review

A typical formal review has the following main phases:

1. Planning: selecting the personnel, allocating roles; defining the entry and exit criteria for more formal review types (e.g. inspection); and selecting which parts of documents to look at.
2. Kick-off: distributing documents; explaining the objectives, process and documents to the participants; and checking entry criteria (for more formal review types).
3. Individual preparation: work done by each of the participants on their own before the review meeting, noting potential defects, questions and comments.
4. Review meeting: discussion or logging, with documented results or minutes (for more formal review types). The meeting participants may simply note defects, make recommendations for handling the defects, or make decisions about the defects.
5. Rework: fixing defects found, typically done by the author.
6. Follow-up: checking that defects have been addressed, gathering metrics and checking on exit criteria (for more formal review types).

Roles and responsibilities

A typical formal review will include the roles below:

Manager: decides on the execution of reviews, allocates time in project schedules and determines if the review objectives have been met.
Moderator: the person who leads the review of the document or set of documents, including planning the review, running the meeting, and follow-up after the meeting. If necessary, the moderator may mediate between the various points of view and is often the person upon whom the success of the review rests.
Author: the writer or person with chief responsibility for the document(s) to be reviewed.
Reviewers: individuals with a specific technical or business background (also called checkers or inspectors) who, after the necessary preparation, identify and describe findings (e.g. defects) in the product under review. Reviewers should be chosen to represent different perspectives and roles in the review process, and should take part in any review meetings.
Scribe (or recorder): documents all the issues, problems and open points that were identified during the meeting. Looking at documents from different perspectives and using checklists can make reviews more effective and efficient, for example, a checklist based on perspectives such as user, maintainer, tester or operations, or a checklist of typical requirements problems.

Types of review::

A single document may be the subject of more than one review. If more than one type of review is used, the order may vary. For example, an informal review may be carried out before a technical review, or an inspection may be carried out on a requirements specification before a walkthroughwith customers. The main characteristics, options and purposes of common review types are:

Informal review::
Key characteristics:

• No formal process.
• There may be pair programming or a technical lead reviewing designs and code.
• Optionally may be documented; may vary in usefulness depending on the reviewer.

Main purpose:

• Inexpensive way to get some benefit.

Walkthrough::
Key characteristics:

• Meeting led by author;
• Scenarios, dry runs, peer group;
• Open-ended sessions;
• Optionally a pre-meeting preparation of reviewers, review report, list of findings scribe (who is not the author);
• May vary in practice from quite informal to very formal;

Main Purposes:

• Learning
• Gaining understanding
• Defect finding.

Technical review::
Key characteristics:

• Documented, defined defect-detection process that includes peers and technical experts;
• May be performed as a peer review without management participation;
• Ideally led by trained moderator (not the author);
• Pre-meeting preparation;
• Optionally the use of checklists, review report, list of findings and management participation;
• May vary in practice from quite informal to very formal;

Main Purposes:

• Discuss
• Make decisions
• Evaluate Alternatives
• Find Defects
• Solve Technical Problems
• Check conformance to specifications and standards.

Inspection::
Key characteristics:

• Led by trained moderator (not the author)
• Usually peer examination
• Defined roles
• Includes metrics
• Formal process based on rules and checklists with entry and exit criteria
• Pre-Meeting preparation
• Inspection report, list of findings
• Formal follow-up process
• Optionally, process improvement and reader

Main Purpose:

• Find defects.

Walkthroughs, technical reviews and inspections can be performed within a peer group –colleagues at the same organizational level. This type of review is called a “peer review”.

Success factors for reviews::

Success factors for reviews include:

• Each review has a clear predefined objective.
• The right people for the review objectives are involved.
• Defects found are welcomed, and expressed objectively.
• People issues and psychological aspects are dealt with (e.g. making it a positive experience for he author).
• Review techniques are applied that are suitable to the type and level of software work products and reviewers.
• Checklists or roles are used if appropriate to increase effectiveness of defect identification.
• Training is given in review techniques, especially the more formal techniques, such as Inspection.
• Management supports a good review process (e.g. by incorporating adequate time for review activities in project schedules).
• There is an emphasis on learning and process improvement.

Static analysis by tools::

The value of static analysis is:

• Early detection of defects prior to test execution.
• Early warning about suspicious aspects of the code or design, by the calculation of metrics, such as a high complexity measure.
• Identification of defects not easily found by dynamic testing.
• Detecting dependencies and inconsistencies in software models, such as links.
• Improved maintainability of code and design.
• Prevention of defects, if lessons are learned in development.

Typical defects discovered by static analysis tools include:

• Referencing a variable with an undefined value;
• Inconsistent interface between modules and components;
• Variables that are never used;
• Unreachable (dead) code;
• Programming standards violations;
• Security vulnerabilities;
• Syntax violations of code and software models.

Static analysis tools are typically used by developers (checking against predefined rules or programming standards) before and during component and integration testing, and by designers uring software modeling. Static analysis tools may produce a large number of warning messages, which need to be well managed to allow the most effective use of the tool. Compilers may offer some support for static analysis, including the calculation of metrics.

ISEB/ISTQB Foundation Documents::
Below are some of the documents which can be referred for your ISEB/ISTQB foundation in software testing.Click on the link to download the file.

ISEB Foundation Chapter3