Review is the process of examining software related documents such as Requirement documents, design documents, user stories, test plan, test specification etc. This gives an opportunity to the team members, managers and clients to get clarity on the requirements and bridge the gap. Suggestions from the team members can be taken on improving the product quality and to make sure that none of the requirements are missed.
What do we review? – Everything created has to be reviewed. The following are some of the common artifacts reviewed:
- Test plan
- Test scenarios
- Test templates
- Test cases
- Test data
Reviews can be broadly classified into,
- Informal review
- Formal review
Before stating Review, we do understand static and dynamic testing first.
So let’s have a look on Static and Dynamic Testing.
Static Testing v/s Dynamic Testing:
Static testing is done basically to test the software work products, requirement specifications, test plan, user manual etc. They are not executed, but tested with the set of some tools and
processes. It provides a powerful way to improve the quality and productivity of software development.
Dynamic Testing is basically when execution is done on the software code as a technique to detect defects and to determine quality attributes of the code. With dynamic testing methods,
software is executed using a set of inputs and its output is then compared to the the expected results.
Static Review and its advantages
Static Review provides a powerful way to improve the quality and productivity of software development to recognize and fix their own defects early in the software development process.
Nowadays, all software organizations are conducting reviews in all major aspects of their work including requirements, design, implementation, testing, and maintenance.
Advantages of Static Reviews:-
1. Types of defects that can be found during static testing are: deviations from standards, missing requirements, design defects, non-maintainable code and inconsistent interface specifications.
2. Since static testing can start early in the life cycle, early feedback on quality issues can be established, e.g. an early validation of user requirements and not just late in the life cycle during
3. By detecting defects at an early stage, rework costs are relatively low and thus a relatively cheap improvement of the quality of software products can be achieved.
4. The feedback and suggestions document from the static testing process allows for process improvement, which supports the avoidance of similar errors being made in the future.
Roles and Responsibilities in a Review
There are various roles and responsibilities defined for a review process. Within a review team, four types of participants can be distinguished: moderator, author, scribe, reviewer and
manager. Let’s discuss their roles one by one:-
1. The moderator: – The moderator (or review leader) leads the review process. His role is to determine the type of review, approach and the composition of the review team. The moderator also
schedules the meeting, disseminates documents before the meeting, coaches other team members, paces the meeting, leads possible discussions and stores the data that is collected.
2. The author: – As the writer of the ‘document under review’, the author’s basic goal should be to learn as much as possible with regard to improving the quality of the document. The author’s
task is to illuminate unclear areas and to understand the defects found.
3. The scribe/ recorder: – The scribe (or recorder) has to record each defect found and any suggestions or feedback given in the meeting for process improvement.
4. The reviewer: – The role of the reviewers is to check defects and further improvements in accordance to the business specifications, standards and domain knowledge.
As the term suggests, these types of reviews will not have a trained moderator and it will not be a structured one. The Minutes of meetings will not be recorded.
Normally formal reviews will be led by a trained moderator and it will be a structured one. This includes more formal approaches like walkthroughs, technical reviews and inspections.
Phases of a formal Review
A formal review takes place in a piecemeal approach which consists of 6 main steps. Let’s discuss about these phases one by one.
The review process for a particular review begins with a ‘request for review’ by the author to the moderator (or inspection leader). A moderator is often assigned to take care of the scheduling (dates, time, place and invitation) of the review. The project planning needs to allow time for review and rework activities, thus providing engineers with time to thoroughly participate in reviews. There is an entry check performed on the documents and it is decided that which documents are to be considered or not. The document size, pages to be checked, composition of review team, roles of each participant, strategic approach are decided into planning phase.
The goal of this meeting is to get everybody on the same page regarding the document under review. Also the result of the entry and exit criteria are discussed. Basically, During the kick-off meeting, the reviewers receive a short introduction on the objectives of the review and the documents. Role assignments, checking rate, the pages to be checked, process changes and possible other questions are also discussed during this meeting. Also, the distribution of the document under review, source documents and other related documentation, can also be done during the kick-off.
In this phase, participants work individually on the document under review using the related documents, procedures, rules and checklists provided. The individual participants identify
defects, questions and comments, according to their understanding of the document and role. Spelling mistakes are recorded on the document under review but not mentioned during the
meeting. The annotated document will be given to the author at the end of the logging meeting. Using checklists during this phase can make reviews more effective and efficient.
4. Review Meeting
This meeting typically consists of the following elements:-
During the logging phase the issues, e.g. defects, that have been identified during the preparation are mentioned page by page, reviewer by reviewer and are logged either by the author or by a scribe. This phase is for just jot down all the issues not to discuss them in detail. If an issue needs discussion, the item is logged and then handled in the discussion phase. A detailed discussion on whether or not an issue is a defect is not very meaningful, as it is much more efficient to simply log it and proceed to the next one.
The issues classified as discussion items will be handled during discussion phase. Participants can take part in the discussion by bringing forward their comments and reasoning. The moderator also paces this part of the meeting and ensures that all discussed items either have an outcome by the end of the meeting, or are defined as an action point if a discussion cannot be solved during the meeting. The outcome of discussions is documented for future reference.
At the end of the meeting, a decision on the document under review has to be made by the participants, sometimes based on formal exit criteria. The most important exit criterion is the average number of critical and major defects found per page. If the number of defects found per page exceeds a certain level, the document must be reviewed again, after it has been reworked. If the document complies with the exit criteria, the document will be checked during follow-up by the moderator or one or more participants. Subsequently, the document can leave or exit the review process.
Based on the defects detected and improvements suggested in the review meeting, the author improves the document under review. In this phase the author would be doing all the rework to ensure that defects detected should fixed and corrections should be properly implied. Changes that are made to the document should be easy to identify during follow-up, therefore the author has to indicate where changes are made.
After the rework, the moderator should ensure that satisfactory actions have been taken on all logged defects, improvement suggestions and change requests. If it is decided that all
participants will check the updated document, the moderator takes care of the distribution and collects the feedback. In order to control and optimize the review process, a number of
measurements are collected by the moderator at each step of the process. Examples of such measurements include number of defects found, number of defects found per page, time spent
checking per page, total review effort, etc. It is the responsibility of the moderator to ensure that the information is correct and stored for future analysis.
Types of Formal Review
A walkthrough is conducted by the author of the ‘document under review’ who takes the participants through the document and his or her thought processes, to achieve a common
understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or cannot easily understand software
development documents. The content of the document is explained step by step by the author, to reach consensus on changes or to gather information. The participants are selected from different departments and backgrounds If the audience represents a broad section of skills and disciplines, it can give assurance that no major defects are ‘missed’ in the walk-through. A walkthrough is especially useful for higher-level documents, such as requirement specifications and architectural documents.
The specific goals of a walkthrough are:-
• to present the document to stakeholders both within and outside the software discipline, in order to gather information regarding the topic under documentation.
• explain and evaluate the contents of the document
• establish a common understanding of the document
• examine and discuss the validity of proposed solutions and the possible alternatives
2. Technical review
A technical review is a discussion meeting that focuses on technical content of a document. It is led by a trained moderator, but also can be led by a technical expert. Compared to inspections,
technical reviews are less formal and there is little or no focus on defect identification on the basis of referenced documents. The experts that are needed to be present for a technical review
can be architects, chief designers and key users. It is often performed as a peer review without management participation.
The specific goals of a technical review are:
• evaluate the value of technical concepts and alternatives in the product and project environment.
• establish consistency in the use and representation of technical concepts.
• ensuring at an early stage, that technical concepts are used correctly;
• inform participants of the technical content of the document.
Inspection is the most formal review type. It is usually led by a trained moderator (certainly not by the author).The document under inspection is prepared and checked thoroughly by the
reviewers before the meeting, comparing the work product with its sources and other referenced documents, and using rules and checklists. In the inspection meeting the defects found are
logged. Depending on the organization and the objectives of a project, inspections can be balanced to serve a number of goals.
The specific goals of an Inspection are:
• help the author to improve the quality of the document under inspection.
• remove defects efficiently, as early as possible.
• improve product quality, by producing documents with a higher level of quality.
• create a common understanding by exchanging information among the inspection participants
Points to remember:
Reviewing is not a process that is limited to manual testing teams. Automation teams also perform code walkthroughs, design reviews etc
Reviews increases the quality of the software products and helps in finding the defects and requirement gaps at the early stages of development. This will reduce the amount of rework required and there by increases the efficiency