The other week I was asked by someone on the Testers Slack for how I go about doing a code review from the perspective of a tester. I figured that I should share this in case others are interested in my thought process for it. This post will be my idealized thoughts on it, even if I sometimes shortcut a bit.
First thing’s first, know what you’re reviewing
First, a mea culpa from me. I have definitely skimmed this step more than I should in the past, and it usually means I need to go back and figure out what I missed.
What I mean by this is that you should take the time to review the story/requirements up front. If you’re not sure about a requirement or an acceptance criteria, ask the person whose work you’re reviewing. If you both have different understandings of the work, then talk to a Product Owner or some other domain expert.
Feel free to jump back to the story as reference.
Second thing’s second, focus on what the team relies on you for
If you’re a tester (or performing that role for the team), don’t focus on the code itself. Look at the tests that are there, then look for tests that you think should be there. Looking at the code is also useful, but not where you’ll add value to the code review.
Make sure to comment not just on the contents of the test, but also how it is constructed. Make sure that patterns and styles are followed correctly.
Miscellaneous thoughts
Most of my career has focused on system and UI level tests. I do sometimes review integration and unit tests fairly closely, but I tend to take longer on those (and the developers are typically more responsible for that level of testing). If you’re more focused on those levels, it probably makes more sense to focus on the code more than I do.
If your process is like ours, code reviews are open to everyone, but one person is typically the main ‘reviewer’ who looks into the code review more carefully than others. Typically, I mark myself as the main reviewer if the tests are a main focus of the review.
