One common question among many QAs is whether they should actively participate and approve the code review for application code. The answer to this query is NO.
Well, many companies have adopted a culture of raising a Pull Request (PR) to be thoroughly reviewed and approved by peers before merging it into the master branch. While this practice is widely acknowledged and mostly involves developers, architects, and CTOs, the question arises regarding the involvement of QA in code reviews.
As I mentioned earlier, it is not essential for QAs to be part of the code review process. However, if QA involvement in code review is not considered essential, how should they engage with code change to derive benefits for their testing? Or, should they simply ignore the code change and test as they do conventionally?
In this blog post, we will walk through the many benefits of QA reviewing the application code and how they should engage with it even when lacking an understanding of the application code to make their testing efforts more efficient and effective.
Code Review – Introduction
A practice in the software development process of examining code changes by peers before it gets merged into the main (master) branch. The primary goals are to catch defects early, maintain code quality, and ensure that the changes align with the project’s coding standards and design principles. Traditionally, this process does not include the QA members of team and mostly considered to be a responsibility of developers.
However, in my experience, code reviews involve looking after naming conventions, asking for a refactor, or mostly code maintenance aspects. Very rarely have I seen developers identifying defects from code reviews.
QA Involvement in Code Reviews: Is it Necessary?
No, QA involvement in code reviews is not necessary, and it should never be. Instead, it should be the willingness of QA professionals to decide whether they want to engage in code reviews before commencing their testing efforts.
I generally do not participate in code reviews, but before I pick the changed code for testing, I go through the PR to understand the changes. I know this is a delayed process, as it would have been better if I engaged earlier and found any potential issues, but my rationale behind this activity is mainly to plan my testing accordingly.
Many times, I do not get the full understanding of the changed code as I lack familiarity with front-end stacks. However, by looking at the code, I can identify the files that have been changed and assess the test coverage. Even if the unit test code is difficult to read, the test names, test data, and assertions provide me with insights into what has been covered by the developer.
Based on my understanding of code change, I proceed for further testing, insights which I gained from code review helps me to plan my exploratory testing as now I am very much familiar with different test scenarios which are already covered at unit and integration level by developer.
For example, if the application code involves an if-else conditional logic and the unit test uses different test data to cover the if-else conditional block, I plan a similar set of test data in my end-to-end test. This approach allows me to verify the if-else implementation while the system is completely integrated.
As I mentioned, for me, code review is mainly an aid for planning my testing. For that reason, I focus on the following aspects while going through the code change:
- Missing Test Coverage: I assess the test coverage added by developer for the changed code, identifying any gaps that may exist. This ensures comprehensive test coverage at the unit and integration levels.
- Defect Identification: If I can understand the changed code and its business logic, I look for defects. To be honest, I focus on simple defects, such as identifying scenarios where the code execution enters the catch block within a try-catch structure and ensuring it aligns with business expectations. Similarly, I examine cases where the code enters the else condition block. I look for logs added at different stages to identify if we are logging any thing which we should not.
- Impact Analysis: By reviewing the changed code, I gauge the impacted areas. As a rule of thumb, if a class name matching the feature is changed in this code, it is considered an impacted area. However, I prefer to cross-check with the developer to avoid unnecessary effort if there is no business logic change in the class.
- Test Data Understanding: I look for test data used in unit tests. This insight helps in planning testing scenarios which helps me designing test data for my end to end testing.
- Static Testing Report: In a few projects where I worked, my team used to integrate PRs with many other tools that perform static code analysis, recommending code improvements or identifying vulnerabilities. Since the fixes recommended by these static analysis tools can be costly, the team generally decides to maintain a backlog for them. However, sometimes these static analysis tools discover super critical issues that need immediate attention, which may get skipped by developers. In such cases, as a QA, I keep an eye on such recommendations and, if needed, I raise them within the team.
As mentioned earlier, QA involvement in code reviews need not be a quality gate, but it can significantly help QA professionals plan their testing effectively. This is why I recommend QAs to engage with code reviews based on their comfort level.
What if there is no feature branch?
Many companies practice trunk-based development to streamline their branching strategy. In trunk-based development, all code directly goes to the master branch, and typically, there won’t be any code review generated.
In such cases, a question may arise: how can QAs look into Pull Requests? Well, git diff will always be there, and QAs can check the differences before they start their testing.
