Last week, we had the distinct pleasure of hosting a webinar with Chris Kenst entitled, “Participating in Code Reviews as a Tester”. In this webinar, Kenst showed that even without coding skills, testers can – and should – take part in code reviews.
At TestCraft, we were excited to host this webinar because we are passionate about testers getting more involved in the software development process. There are many ways to bridge the gap that exists between testers and developers. Along with codeless automation, doing code reviews helps testers play a more active role in software development without previous coding skills.
As a codeless test automation platform, we also believe in investing in processes that help testers adopt a “shift-left” mindset. Using TestCraft’s visual way of creating automated test scenarios, QA teams can test even before an application is ready. Both creating automated test scenarios and participating in code reviews can help with catching bugs early in the process, resulting in increased savings for the company. The earlier your team catches bugs, the lower the overall cost. Together, codeless automation and code reviews can help make software testing faster, more efficient and more productive.
Here is a brief summary of what happened in the webinar below, and you can also listen to the full recording here.
Why Participate in Code Reviews
In the first part of the webinar, Kenst discussed why he is encouraging testers to participate in code reviews in the first place. There is a major difference between reading code and writing code. While many testers have little to no code-writing experience, it is much simpler to learn how to read code. At the very least, testers are able to familiarize themselves with markers in code that can help them look for bugs more easily.
He continued that code reviews are not only very common in development, but are a great opportunity for testers to get more involved in the software development process. There is a big learning process involved when looking over a set of changes in code. Since testers question differently from developers, it’s a great way for them to become part of this discussion.
Participating in code reviews has another, less obvious benefit for testers. Not only can testers play a stronger role in the SDLC, but they can improve their own testing efforts as well. With the additional context of code reviews, testers can actually adapt their scenarios in response to what they learned. Collaborating with developers in this way allows testers to work more efficiently and become more technical in their testing approach.
Asking the Right Questions to Understand Changes
Understanding context is an invaluable asset that testers have during code reviews. In Kenst’s personal experience, he started receiving pull requests specifically because he understood the bugs in a larger context. To use that context effectively during a code review, it’s important to ask the right questions.
Kenst presented a list of possible questions that can help testers better understand the changes happening in a pull request. Examples of questions included asking about text changes to taking a mental inventory of the number of files that changed. He also suggested thinking of code changes in terms of categories: documentation, bug fixes, maintenance, refactors and new features. This can help testers better determine which bug fixes require a simple two-line change and which need more attention.
Another important point that he mentioned was to pay attention to the third-party services that your development team is using as part of their CI system. First, having access to these third-party services can provide data that you can use later for testing. Second, you can see where they are used, which adds to your testing because you can get a fuller understanding of how they function within an app.
Ultimately, getting into code reviews takes practice, a lot of trial and error and constantly asking for more information. Whether you get started by searching on Google or pairing with a developer, this will all give you the increased contextual awareness you need to do an effective code review. You will both bridge the gaps in your own knowledge and fill in the developers’ gap in their knowledge.
How to Get Started with Code Reviews
To end the webinar, Kenst went through some practical examples of code reviews that spanned different types of scenarios. Working in a Github repository, he went through the pull requests tab and gave everyone a glimpse of how to read the code, search for the issue and make a suggestion to fix it. He also offered different best practices, such as using the split setting to get a better visual comparison of the changes that are happening in the code.
He then offered recommendations for how testers can get started with code reviews on their own. Pairing with someone who does code reviews at your job, whether a developer or someone else, is a great place to start. This will help you better understand how to conduct code reviews in your specific environment. He also recommended that any GitHub project is a great opportunity to start learning how to do code reviews. Finally, he invited everyone to do code reviews his own OS list of software testing conferences, TestingConferences.org.
At the end of the webinar, Kenst answered a few questions from the audience. For your convenience, you can read the questions and his answers below:
Q: How do you approach introducing code reviews to a team?
A: For a testing team, start introducing this one tester at a time. When I started doing code reviews, I became a big advocate of everyone else taking part. Once I learned how to do code reviews on my own, I would pair with other testers and teach them how to do code reviews as well.
From there I was able to show them how looking at these changes could help them make improvements to their testing strategy. You should implement it, get yourself up to speed and then share your newfound skills. If your company does not do code reviews, then reach out to your development team and ask if there is a campaign on the side that you can look at to provide a review. They are usually very happy to accept the help and can work with you to do the review as well.
Q: How do you do a code review if you follow an agile methodology?
A: It’s built-in. Typically what happens in an agile workflow is there is a development in progress, they create a branch and then the developer is “done” working on it when a pull request comes up. Typically another developer will then do a code review and either approve or decline those changes. Once they’re approved, they move on to testing and then go into production. By definition, code reviews are built into an agile development process.
Q: Is it possible to see the pre and post-code changes, or compare two versions in the same branch?
A: Using Github, this is very easy to see. The pull request’s file change view shows what the code was like before the changes and after the changes. You can also use the command line or any other tool that helps with code reviews.
Q: How do you compare the same code in two different branches, in case the code works in one branch but doesn’t in another?
A: This is more of a debugging scenario. In those cases, I would check out the branches themselves and try to run the code in each. If you can run the code in both branches, you can start looking at the differences and compare them. This may not be a pull request, rather it may be something you can do on the command line. It’s something that’s fairly easy to visualize.
Q: In your opinion, does QA do initial code review or does this qualify as a peer review?
A: It depends on your organization, but I think they’re the same thing. Where I started, testers also handled all the releases, so it makes sense for us to do code reviews and merge them. It depends on where you fit in your organization to determine how much you will do.
Q: How would you approach the situation if If the sprint cycle is just 15 days and QA cannot do a code review?
A: At the organizations where I’ve worked, we’ve done multiple deploys every day. So if you have 15 days between deploys, you have time to do code reviews. I’m not suggesting that you break with your workflow where you expect someone to assign code reviews to you. That’s a bigger organizational change. Initially, if you see that there are pull requests open and in a code review state, and you know that you will eventually be testing the changes that happen from those requests, I would recommend you take a look at these pull requests. Whether or not you approve or merge those pull requests, that’s a larger decision that you can make with your organization.
As part of the testing process, you should see what changes coming down the pipeline, and you can find those changes in pull requests. Then you can take some time – around thirty minutes per day – to figure out what’s coming up for the rest of the week. Depending on complexity and volume, you can start with one code review per day, or even one code review every few days. Regardless of what you do, you should be able to look actively at where those pull requests are, determine if they will have an impact on you or your testing, and take some time to look at them and see what is happening.