NOTE: This was written as part of the Ministry of Testing's Blogger's Club challenge. If you are interested in learning testing, I encourage you to check out MOT.
What is code review?
It's both looking over the code personally, and letting the linter - with rules decided as a team - inspect the code.
Why code review?
Code review is the first step after the development is 'ready for testing'. It's the first step of post development testing - you've scoped out the work, analysed the requirements, had a session with the developer and designer to discuss. This is the last chance to catch bugs without intense 'traditional testing', as it were.
I like it to be the first step I take before I start testing. I may not comment, but I definitely read it. I too often regret when I don’t.
It's a place to catch issues you would take a longer time to find when testing with other methods - security flaws, small but important business rule mis-interpretations, commented out code, code that could be tested with integration and unit tests that aren't - and issues you can't find when testing with other methods that can lead to product quality issues down the line, like hard to understand code, unclear names, de-standardisation of naming styles.
It helps you learn how to code. That is useful for the inevitable programming you'll end up doing - whether it is fixing minor bugs, creating testing tools, using testing tools, or test automation. You see examples of different patterns and when they should it shouldn’t be used, out in the wild.
It helps defect replications later - you understand the code, and therefore the most prominent scenarios that the code fixes are referring to just by reading the code. If fix tickets are ever lacking the required details, or they assume knowledge you don't yet have, you can reverse engineer the intent, and then talk to the engineers and product manager when they are available to fill in the blanks.
This makes doing code reviews both a potential workaround to organisational issues, and a skill enhancer.
Ultimately, it helps you refine your questioning skills - which is ultimately what we are doing as testers. Making and recording observations and asking questions. You practice asking questions, while both broadcasting your assumptions, and assuming that you may be missing context that the developers have. This improves your communication skills.
Top comments (5)
Nice article! I wanted to just drop a comment and add that academic research in software engineering also tends to indicate that code review is one of the most effective quality control methods in software projects. Specifically, it's perhaps the bets way for catching architectural drift and/or erosion.
Is that your paper on architectural drift I see on page 1 Google? I read it here - researchgate.net/publication/33938.... Nice work.
yep that's me! thanks!
In my experience, and in a white paper on code reviews from Microsoft, the problem with code reviews is that they tend to be gloss level.
Small code changes that have changes that are self-contained / local to that part of the code can be code reviewed effectively.
Large changes (100+ line changes) across many files tends to be overwhelming on the code reviewers, and the quality of the review goes way down, and the reviewers tend to comment on inconsequentials like indentation or typos in comments, rather than structural, how the behavior changes, and interactions.
Code reviewers that are intimately familiar with the code being changed can have a much more in depth and meaningful reviews. But even original authors who have been out of that code for a while will have less effective code reviews.
The best code reviews are pair programming or mob programming, which the code changes are undergoing immediate and interactive continuous code reviews (CCR). But unless a team is doing something like Extreme Programming, they probably are not engaged with pair programming or mob programming. CCR is the best bang-for-the-buck code review process.
Completely agree, its very underrated! Especially like your point on how it helps you to learn how to code.