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.
Summary
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.
