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

Test Automation: Good, Bad and Ugly

The modern approach to software quality and software development life cycle requires that business guys, developers and testers understand that the long manual test phase, although often still necessary, must be reduced to a minimum and replaced by test automation. Working in continuous delivery and continuous integration environment requires us to create automated tests that run on demand, checking our application integration and it’s core functionality correctness. However, there are still many problems with designing and writing automated tests, resulting in their costly maintenance or abandonment in favour of a return to manual processes.
In this article I will focus on describing common good practices of test automation. This post is more than an overview than complete reference guide. Broader aspects, such as the Page Object pattern or Page Factory will be described in detail in a separate article on this blog. Although most practices apply for every types of automated tests, thi…

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…

REST-Assured: going deeper

In my previous post I described the basic REST-Assured usage – the lightweight framework for testing RESTful services. Despite the fact that described range of functionalities would be enough in most cases,REST-Assured has a lot more to offer. In this post I would like to bring some more advanced examples of the framework usage.

I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks:

REST-Assured – framework overviewBuilding microservices testing framework
Object Mapping Sending request’s body as string is easy and straightforward, but it can be inconvenient in the case of more complex operations on request / response properties. Proven solution for this is a good-known serialization of request/response body to objects. REST-Assured supports object mapping to (and from) JSON and XML. For JSON you need either to have Jackson or Gson in your classpath and for XML you need JAXB. Here is an example of request object serialization using J…