How Code Reviewing Can Help With Quality Assurance

Being in the software industry you may have often heard the term code review. However, the concept of code reviewing is often misunderstood. Often it is overlooked in the software development lifecycle as people feel performing testing should suffice the validation process. And so, they tend to turn a blind eye towards the code reviewing process. However, neglecting code reviewing process could bounce back with major consequences to deal with. We also have a misconception that the code reviewing process is a responsibility for the development team alone. It is not! Code reviewing is a process that should involve not only developers, but QAs and product managers, too. This article is my attempt to help you realize the importance of code review and how as QA, you should be participating in it. We will also look into code review best practices and code review checklist for automation testing using Selenium WebDriver.

What Is Code Review And Its Objective?

Code reviewing is a practice where the source code is broken into small pieces, which are inspected by the supervisors or seniors in the team to be carried out just before testing. It is a process mostly followed in Agile methodology.

The main objective of code review is to detect mistakes, catch early bugs, and ensure that the code follows the standard practices. It can be termed as a two-way communication where both the coder as well as the person who reviews the code learns from one another and remove any potential mistakes which may later impact the product.

Working in an Agile environment, you may often underestimate the significance of code reviewing process. You may think code reviewing is going to be time-consuming, especially when you are running short on deadlines. However, this is where it becomes all the more important. The sooner you review the code and eliminate any blocker or bug possibility for later, the sooner you are able to deliver the product as per the release process. Finding bugs later in the release cycle or post-migration into production turns out to be more expensive and time-consuming. This is why organizations are now following a modern methodology of Shift-Left testing where you incorporate testing right from the client’s requirement gathering phase.

Why Code Reviewing Is Inevitable

If you believe code reviewing isn’t required as long as you are testing, then the below-mentioned benefits may sway you towards thinking differently.

• Early Bug Detection: When bugs are detected at a very early stage in the development phase, it reduces a lot of time during the testing phase. The overall process becomes a lot less expensive. Automation testing reduces the testing effort and time spent; still, there is no better gift than the human nature of detecting and correcting mistakes committed by others.
• Mentoring Juniors: When a freshman joins a project, seniors may not have much time to mentor or guide the junior about the coding practices or train them about how they do their job. The ideal solution in that scenario for a senior developer is to spend at least 20-30 minutes in reviewing the code written by the junior. Regular feedback will allow the new developer to develop his/her skill in coding.
• Age of Agile: Nowadays most organizations follow Agile methodology and require to deliver quality work in time. Code review will enable the organization to develop a quality prototype, free from defects, and developed following the standard protocols.
• Team Cohesion: Frequent review discussion brings the team closer, makes them aware of each other’s strength and weakness and saves them from getting stuck in an isolated environment.
• Compliance to Standards: In the Agile age, the client often requires us to abide by a certain coding standard. However, fresher developers are not often aware of industry standard coding. Frequent reviews help to ensure that the code abides by the rules and standards that have been set by the stakeholders.

Can Code Reviewing and Testing Replace One Another?

Code reviewing and testing are both best practices to be included in a software development lifecycle. However, both are unique in their own ways and must not be confused. It would be wrong to think that you don’t need code reviewing because you have tested in your SDLC or vice versa.

Code review involves inspecting the code which may or may not include checking for bugs. It involves checking whether the style of code is under compliance by all policies, whether there is any breach of security and most importantly, whether the code can be understood easily or not. The goal is to check whether the code is simple, follows all policies and standards, and most importantly, serves its purpose.

Testing, on the other hand, has several categories. The main objective of testing is not to check the code, but to check whether the application works perfectly or not. Testing involves detecting whether there are any bugs in different layers of the application, whether the application satisfies all the requirements of the stakeholders and ensuring that the issues detected are communicated to the concerned team.

Hypothetically, code review can replace testing. In the case of a very small application, if more than multiple reviewers carefully go through the code, they may identify the sections that may raise a defect when unit testing is carried out. Only hypothetically, not realistically.

Testing, either manual or with automation, often follows a fixed approach to check the application flow and find out whether anything is behaving like the way it is not supposed to.

Code review, however, requires manual intervention. The human mind is complicated and may think of scenarios which may not have been pre-programmed while writing a test script. An experienced code reviewer can detect any line of faulty code that may cause breakage at a certain scenario which the tester may not have thought of while writing effective test cases.

However, code review can only replace testing when the application is very small and consists maybe, only a hundred line of codes. In case of a large application, the scope gets larger and no matter how many reviewers work together in inspecting the code, the application may cause breakage when the codes are integrated. That is where testing comes into play.

Testing can, however, never replace code review, either hypothetically or realistically. Although testing may detect all the bugs and get them fixed by the developers, let’s discuss a scenario which will make it clear why it cannot replace code review.

I’ll share my personal experience. Our team was working on a large dynamic web application. After the final testing phase, the entire application was satisfying every user requirements. However, there was one problem – the loading time. Even in the fastest network connectivity, the application took 4-5 seconds to load. By going through a code review phase, we found out that the CSS and scripts were very complex and they could be minimized by a few hundred lines. Doing so, we reduced the loading time to 2 seconds. Thus, it can be concluded that realistically, both code reviewing and testing are integral parts of a software development phase and can never fully replace each other.

How To Participate In Code Review As QA

Code review is considered to be a part of static testing, an activity to be conducted mostly by quality analysts to find out whether any bug can be spotted earlier before the testing phase starts. If the testing team actively participates in code review, it saves a lot of time.

You may wonder how to get started with code review when you are into testing and do not have any experience with development. But the fact is, code reviewing only requires your observational skills, not your coding proficiency. For starters, you may start with automation scripts. Try to look for minor bugs that may result in an incorrect testing sequence. Parallelly, whenever you have time, go through the repository of your application and try to understand what the developers did there.

Also, if someone from your team has been reviewing codes, sit with them and try to get an understanding of how they are doing the job. Check whether they are looking at:

• Log messages which are clearly understandable
• Syntax errors
• Errors caused by spelling mistakes
• Naming conventions

Initially when testers get the opportunity for code reviewing, pairing with someone who is experienced makes the task a lot easier. Although the numerous lines of code initially do not make any sense, keeping up with it enables the quality analyst to find a pattern and slowly get accustomed to the codebase until finally, a time comes when just by looking at a certain section of the application, they can clearly state what business logic is implemented in that section.

Moreover, once the development team observes that the QA team is paying attention to the code, they will gladly explain to them how their code works, thereby increasing the programming knowledge of quality analysts as well as improving the communication between the teams. Thanks to the practice of code reviewing, testers will have the knowledge of what functionality of the project is defined in what part of the code, thus improvising the overall wisdom & teamwork.

Finally, remember one thing. You are not required to be an expert coder to carry out a code review session. Anyone with basic coding knowledge can review code. You are only needed to take a look at the changes and ask what, why, and how a thing is done. Start with small changes and learn more about them and wherever you feel about any discrepancy, comment it and ask the coder to clear your doubt. And if you are managing the entire project, make sure to include code reviewing and testing as mandatory phases to carry out during any software development lifecycle. This will ensure that a quality product is delivered and your organization’s reputation is maintained.

Ways To Perform Code Review

Let’s get started with how you can review the code. Depending on the size of your application, there are 2 types of code reviews you may carry out.

• Formal Code Review: It is a detailed process that requires you to collaborate with multiple participants and work in multiple phases. This is the traditional process where the team attends meetings and check the code line by line, traditionally using printed copies. Inspections are thoroughly done and the method is found to be effective in finding defects.
• Lightweight Code Review: This process is also quite effective and requires less effort that formal code review. Conducted as a part of normal development procedures, there are 4 ways by which this review is carried out.
  • Over the Shoulder: Here, a developer looks at another’s code while the latter walks the former through the code, explaining what is done in it.
  • Passing Emails: Whenever a check-in is made, the application that manages the source code, automatically triggers a mail to the reviewer.
  • Pair Programming: 2 coders develop the code in the same workstation while constantly reviewing each other’s work.
  • Tool Assisted Review: Specialized tools are available nowadays meant for code reviewing and testing. The peer uses those tools to review the code and comment as needed.

Code Review Checklist For Selenium Automation Testing

Although there are certain best practices which we shall discuss later that will result in a flawless code review, if you are conducting automation testing with Selenium WebDriver for cross-browser testing of your website, there are certain factors to check while reviewing your code.

• Instead of Xpath, use CSS locators wherever possible.
• Page objects must be used for all the DOM objects which are used as selectors.
• Avoid data management structures that are complex.
• For handling the wait issues, the tests should mostly depend on the framework.
• For data search functionalities, minimum texts are used.
• Long element locators are often brittle. Avoid using them since the layout on which they are bound, tend to change.
• Page objects should be unique as well as robust.

Code Review – Best Practices To Follow

Just like coding and testing, you need to keep in mind some code review best practices as well. Let’s discuss them in details.

• Know What You Are Looking For: Set up your goal before reviewing. Prepare a list which may include coding style, structure, the complexity of logic, readability. In short, include items which cannot be reviewed during automated testing and requires human intervention. Ask questions like “Do I know what this code is doing?” or “Does this code complies by client specified coding standards?” is considered as a great code review best practices and you will easily prepare the items to check for in the code.
• Build & Test Prior To Review: In the current age of continuous integration and continuous delivery, it is ideal to build and test the code before manually reviewing it. This ensures that the code is stable and saves a lot of time. After a successful build, when the code passes all automated tests, it is a best practice to code review and ensure that a bug-free code has been pushed to the developer’s code line.
• Don’t Take Too Long To Review: As a part of code review best practices, you need to ensure that you are not spending more than the average time in code review. It will be better if you review the code in short breaks to ensure that your brain gets the required interval and you can start again with a fresh mind. Frequently reviewing the code will also help you think about new scenarios and improve the code’s quality.
• Your Review Must Not Hurt: Instead of being critical, be constructive in your review. Ask questions instead of making statements. Also, praise the developer for their job. Your feedback in the right tone must not hurt them, it should rather inspire them to correct their mistakes and make sure it does not happen again.
• Communicate The Expectations & Goals: Be clear about the goal of the review as well as expectations of the reviewer. If the reviewers are working under you, then as a part of code review best practices, it is recommended for you to provide them with a checklist to help them check the mandatory stuff and ensure that the entire team’s code is reviewed in a consistent manner.
• Include Your Entire Team: No matter how senior or experienced your programmers are, everyone must review the codes along with getting their codes reviewed. The performance level will increase relatively when they will know that their code is going to be reviewed. Try to include an architect along with a developer while reviewing the code. Both of them will detect different issues, while will ultimately impact the overall application’s design.
• Automate Wherever Needed: Some things in the code should be checked manually. Some other things are there that can be checked by using the proper tools. Automate wherever you feel manual intervention is not needed. Tools like code analyzers compare the code with coding rules and find out potential issues.
• Consider Code Reviewing To Check Cross-Browser Compatibility: We all know that browser compatibility issues with Javascript, HTML/CSS occur when a particular CSS style or a JS functionality is not supported by a specific browser. Once we worked on an application where the use of certain styles was restricted since the application was meant to run perfectly in an older version of Internet Explorer, the browser that has caused pain to developers worldwide for its incompatibility with all the latest web technologies. After weeks of coding, a review session was carried out and it was found that while writing the CSS, at certain sections in the code, we missed out browser specific vendors. Corrections were made immediately after which, the application went to the testing phase. Needless to say, it passed the browser compatibility testing flawlessly. If the code review was not carried out, defects would have been caught during cross-browser testing, subsequently putting the developers in a kind of rush to find out what caused the issue.
• Nurture a Positive Environment: From a managerial perspective, it is important to maintain a positive work culture as a part of code review best practices. A positive environment could be very helpful when the code is reviewed. It doesn’t matter who caused the bug. What matters is that the bug has been caught and fixed. Praise the correspondent person and overall it will help in maintaining the product’s quality.
• Rely on Code Review Tools: Instead of manually checking and writing down issues, use code review tools which save the effort by enabling inline comments and bug reports.

I hope you now realize the relevance of code reviewing in the SDLC, along with its distinction from testing. If you are a product manager then it is vital for you to incorporate code reviewing process in your release cycle, in case it already isn’t. In case it is incorporated, you need to organize the bandwidth and resources efficiently and make sure that the participation is active from both developers as well as testers. If you are a QA who has been afraid to step into code reviewing then you need to change your perception and jump right in. Lastly, if you are a developer, then you have to make sure to loop in the product managers and software testers in the code reviewing process for ensuring a crystal clear transparency. Happy reviewing!