Skip to main content

Code review for Testers

Code reviews are essential for an software engineering process. Popularised with open-source community, they becoming a standard for every development team. When done right, can not only benefit in avoiding bugs and better code quality, but also be instructive for a developer.

Although code reviews and pull requests are well popularised through developers, it’s still kind of an unknown land for testers. In most of the scrum teams I’ve worked with, test engineers weren’t participating in pull-request reviews by default. It’s high time to change testers (and teams!) mindset. In this post I would like to consider code review from test engineer perspective and point it’s benefits, both for testers and scrum teams.

Wait, but ISTQB says… 

I need to do a little disclaimer first: yes, I’m familiar with black/grey box testing approach. I do consider that testing without knowing implementation details can be beneficial. This aims problems of tendency due to knowledge of decision points and flow conditions. However, black-boxed functional testing works best mostly when preceding big releases or after long implementation iterations. I belief that in process of small, incremental changes and frequent deliveries, having a tester who knows the code is highly beneficial in the aspect of product quality. This lets him to focus on actual changes and acquainting system architecture.

This kind of incremental testing (could we say agile?) obviously doesn’t exclude black box testing before big releases.

Tester reviewing team’s implementation 

So you’re a test engineer in scrum team – why you should do code reviews? Isn’t it convenient to wait until changes would be on test environment and start your work then? First of all, test engineer is responsible for product quality, and quality matters in whole process. Modern test approach says lot about requirement analysis or process methodology (with testers often wearing scrum master’s hat), but says lack about coding phase – which is one of the most important parts of the process. Tester, as well as every other member of the team, should take part in code reviews, focusing on implementation quality and their compliance with business requirements.

Second thing is to know the test range. Starting to test with getting familiar with code lets you identify actual scope that needs to be put under the test, as well as the critical spots in implementation, where all the application logic is being made.

Team reviewing tester’s implementation 

It’s common that non-production code, like automated functional tests are treated with less attention. I understand the reasons, however – I think we miss some points here. Automated tests (other than unit or integration) are usually implement by test engineers, who are mostly less skilled in writing code than developers (obviously this is not a rule). In order to develop their knowledge and expertise in programming their code should also be reviewed by peers. This leads not only to better code quality, but also have educational aspect.


Code review is very underestimated stage of testing and quality assurance. If you’re a test engineer working in incremental, agile environment, I strongly belief that jumping into the pull-requests should be an obligatory point, right after acquainting yourself with business requirements. On the other side there’s your code being reviewed by others, which for me was one of the biggest key to develop myself and succeed in field of test automation.

Popular posts from this blog

Notes after TestingCup 2018

On May 28-29th I attended TestingCup conference in Łódź. Having quite unique perspective: this was my second year in row as a Speaker at this conference I want to share some thoughts on the event. Dust has settled, lets go! 

Championship Originally TestingCup is a software testing championship. Wait, what? Yes, the formula is unique: teams and individuals from all around Poland are competing in finding the most bugs and defects in specially prepared application - Mr. Buggy. I don’t have specific data, but since this year’s conference was all english I guess competitors were not only from Poland. As a spectator, I must say that the whole competition looked very professional. There were team shirts and names, podium and trophies (gold cup and cash). 
Some cons? Testing championship is held at the first day of the conference. So this is already a conference, but if you’re not taking part in the championship… there’s not much to do, since all the talks are in the next day. Organizers are aw…

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

Building microservices testing framework

RESTful services and microservice architecture in general are big trends in the industry right now. I’ve noticed it also from this blog’s traffic analytics, where topics related with REST testing get the highest interest. Therefore I’ve decided to create some kind of example framework for RESTful APIs functional testing. Project is based on REST-Assured as a services client, Spock as a testing framework, Groovy and Gradle. You can clone full repository from my github. Tests are run against Wiremock API described in this post. Please consider this project as a kind of bootstrap, since it’s an example, not full-blown test framework. Ok, so as Linus said – talk is cheap, show me the code!
Dependencies Usually, first thing for me after importing new project is opening build.gradle (or pom.xml, in case of maven). In our example, the most important dependencies are REST-Assured and Spock. We’ve also Jackson, for serializing objects, Logback for our logs and snakeyaml for reading .yaml files,…