How Project Managers conduct Code Reviews as a Testing Activity?
Expert managers carry out several types of code reviews that include informal walkthroughs, formal inspections, and paired programming being popular these days. The paired programming involves participation of two developers in a combined development effort at one workstation. For example, one creates a unit test for a class while the other one thinks of the design and implementation of the class that will pass the test. These partners switch their roles too frequently sometimes at least once a day.
Irrespective of the approach used, the objective of the code review activity is to identify the potential coding and design defects manually by evaluating a segment of software. Whether an individual or a team does this activity, doesn�t make a difference.
Let us firstly try to gather the answers of Why, How & Who related to the code review activities
Q. 1: Why do we need to carry out Code reviews?
Code reviews facilitate detection of defects early in development. Additionally,
they motivate developers to write manageable code. When developers know that their peers will review the code, they tend to create more clear and concise programs and do proper documentation of their code.This role of reviews is especially important because writing documentation is often psychologically resented during code construction. Code reviews also improve the technical knowledge of the participants since developers are given an opportunity to learn from each other about the latest coding patterns and new programming tips. Another positive side effect of code reviews is the fact that they facilitate the building of a common team culture through face to face interactions. During such meetings the developers are more likely to pressurize the “odd man out” to follow the team�s standards and practices.
It is an underlying fact that software quality and development productivity drastically increases by code reviews. Recent studies have revealed that traditional code reviews are indeed value-added tasks; they increase development productivity of the current project and they can facilitate future productivity improvements up to 20%.
Results of research on the productivity of paired programming are less conclusive. Quantitative evidences are available that indicate that paired programming improves product quality and reduces time to market. However, more recent research, indicates that productivity improvements depend on the experience and skills of the individuals forming pairs. For example, novice – novice pairs compared with novice solos are much more productive than expert – expert pairs compared with expert solos.
Q. 2: Who should carry out Code reviews?
Developers and the architect are the best-suited personnel for conducting code reviews.
Q. 3: How should we do the Code reviews?
Code reviews allow developers to evaluate the implementation of their co-workers in hopes of turning up possible defects. The scope of the code review is usually determined by use cases: when a developer completes the code required to implement a use case, all the related code should be submitted for review. Alternatively, code can be reviewed incrementally for example, as it is added to the source control system.
The expanded infrastructure can facilitate this process by automatically alerting reviewers about newly modified lines of code once a week. In the latter case, the reviews should be performed after the code is checked in and demonstrated to satisfy coding standards as well as white box testing and black box test progression criteria.
Those parts of the code that show coding standards violations, as identified by the automated coding standards analysis, are a natural starting point for a code review. The violations should be assessed to determine whether they are warranted, and therefore whether the code should be exempt from the required standard, whether the standard should be modified to permit the reported type of violations, or whether the code should be modified to comply with the standard.
In addition, a code review should be conducted every time a regression test failure is reported. The goal of this inspection should be to determine whether the code behavior change was intentional. If the change was intentional, the test cases should be modified to allow for the new expected behavior. Otherwise, the code should be corrected.
Code reviews should be performed on the new, modified code and on the most critical parts of the application.
This type of approach indicates a sense of priority. While focus should be on defect detection, code reviews should also help to identify bottlenecks and performance problems in program segments.
The seriousness of the defects identified during code reviews should be assessed, and severe defects should be reported in the problem tracking system and used in defect analysis and prevention.
Approvals & measurement of code review:
The amount of code that has been reviewed and that still needs to be reviewed should be measured. This number should be used in assigning priorities to the developers� tasks as reported in the “Current Activity Log” report, and in estimating the time needed for testing activities. The lead developer before the integration testing starts should approve all code subject to the review.
The new and modified code that needs to be reviewed should be tracked. Once reviewed and approved by a lead developer, the code should be marked as accepted.
Use of automation tools for code review:
Conformance to coding standards and project specific programming rules can be verified automatically by the use of static analysis tools.
Review of the algorithms and complex parts of code should be done manually. While these types of code reviews cannot be automated, the code covered by reviews can be tracked automatically. Static analysis can be used to help in identifying parts of the code that need to be reviewed, such as segments of code with high cyclomatic complexity.
Selection of the code review tool are based upon its ability to identify new and modified code in the source control system and informing a reviewer or the lead developer on a particular module about the required reviews.
The developers should be provided with a list that tracks the review status (accepted, pending, or needs revisions) of all relevant pieces of code.
Full Study Material for ISTQB Advanced Test Manager Exam
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.