Code reviews in software testing

In a previous article I talked about the value that static testing provides in software quality. In this post we will cover one of the most important static testing processes: code reviews.  

Reviews are evaluation procedures directly focused  on the code produced by developers. This type of analysis is performed manually or using tools and they can be carried out formally or informally. Informal reviews do not follow a standardized process while that the formal ones have all kinds of requirements and documented procedures. 

In which situations will we need formal reviews? The truth is that there is no fixed guideline on this regard, but factors such as product complexity, legal implications, software production cycle model and others, will be taken into account to determine when formal code review is suitable. 

Main tasks in the review of a software product

Planning: In this phase we define the scope of the review: its purpose, the documents being evaluated and the exit criteria used. Likewise, in the
planning we will need to estimate how long and how much effort it will cost and to specify who will do the reviews. 

Beginning of the reviews: It consists mainly on making the object of evaluation (the code) available to those who will review (for example, give access to repositories where scripts are saved). Additionally, the scope, objectives and processes of the review will be explained to those in charge of reviewing. 

Product review and defects search. At this stage, the reviewers already have everything they need to work and start detecting potential errors in the code. 

Bug Reporting and fixing: Potential problems are communicated, overall quality is assessed against exit criteria and a final conclusion is reached, this is, the code is accepted or rejected (i.e is sent back to the developer for rework). Reviewers can make a report with errors found specifying the aspects that need correction. Once the errors have been corrected, the product status and changes are accepted if  they meet the exit criteria. 

Some review techniques 

There are several techniques that we can apply in software review to detect defects. Amongst the the most common ones we can highlight: 

Ad hoc: In ad hoc reviews, reviewers do not receive strict guidelines on how they should conduct the review. This technique requires little preparation since
that it will be as “simple” as reading the code and identify faults sequentially. This
technique is usually applied in informal reviews and is ideal if you have experienced reviewers or people with extensive knowledge of the product. 

Reviews through check-lists: It is a much more standardized technique. Reviewers receive a checklist oriented to possible failures which should be as specific as possible. The value of this technique lies on the strong systematisation of the review. However, they also run the risk of missing several bugs if not updated frequently, therefore, reviewers should pay attention to aspects that might be out of the scope of checklists.

Scenario-based reviews: In this model of software evaluation reviewers receive specific instructions on how to read the program. Reviewers use scenarios to “dry run” the program in which a given feature is tested. 

Role based review. Reviewers examine the software from the point of view of certain stakeholders: internal users, external users, users with more or less
experience etc. There is a variant of this technique called perspective-based review. It is similar to the role-based one but is more extensive; more views are adopted it and requires further examination of the product. Therefore, it is not surprising that experts point out this last technique as the most effective in code review.

Important aspects for effective reviews 

From the organizational point of view there are factors that affect the quality of the findings in a review. We can highlight for example the importance of clear planning after review: well-defined goals, easily measurable exit criteria, review techniques that are appropriate for the product, divide long documents into small units of analysis, etc. A clear organizational model will save a lot of time in the long term because all parties involved will know what they must do at all times. 

Other factors related to reviewers have to do with their specific skills and knowledge. Unlike the dynamic testing, static testing may require high technical knowledge of the product. While it is true that no it would be essential to be a development expert in certain review  techniques, a person used to working with code will find defects not covered in the review plan. 

Finally, it should be noted that in order to have successful reviews it is imperative to provide suitable training to people working on the project (especially for
formal reviews) as well as fostering a culture of continuous learning and trust among peers. This last aspect will be key to make sure that future reviews will be approached from constructive framework that adds value and quality to the project.