30 Days of agile testing — Day 9: Pair with a developer during a code review. Can you identify any risks? Matt Frampton Follow Sep 17, 2017 · 3 min read

For what I expected to be the easiest challenge so far, I actually found this challenge to be the most difficult, but not for the reasons you may expect.

Our team works on a one point story model. This means, any story that is larger than one point, must be broken down into smaller stories, but how, and why, did this make performing a code review difficult?

To answer, I need to provide some context around where the one point stories come from. When we play one-point stories, much of the complexity and business logic is defined during the ticket refinement. If the work requires more than one point, there is either known complexity that we are accommodating for, or there are gaps in our understanding of the problem. So when a ticket is played, it is small with a known scope, but why does this make it hard to code review?! Well….It doesn’t! It makes it faster to review, deliver, and to an extent, test the feature. The problem I encountered during this challenge was simply… trying to find a code review that was pending or in progress.

To facilitate developing small features, quickly, we use pull requests. Code reviews are almost exclusively performed within the context of a code request. Most of the pull requests involve 3–20 lines on average, which means the turn around is rapid. Eventually, I did find a developer to pair with during a code review.

During the the pairing session, I asked them about how they decide what to look out for when performing a code review. Below are a few examples:

Checking that the code and unit tests compile and pass

Unclear naming conventions

Unused variables/classes etc

Violations Single responsibility principles e.g. big classes and methods

Readability of the code(can I understand what it is doing)

What would I do better-

Different techniques, “I wouldn’t have done it like that, but it works so I’m happy with that”

Android specific “gotchas”

The goal for today’s exercise was to identify the risks from a code review, but instead of applying it directly to a one-time code review, I also wanted to understand what the developers considered to be a risk from a code review.

Each of the developers suggested similar topics for what to look out for in a code review, but one thing which was interesting was the order in which it was done. Some developers would read the code through GitHub on the web, whilst others would run the code to check it compiles before even checking a line of code. The line between code reviews and testing can become blurred in small teams, with some engineers performing both roles. The biggest risk I have come across is where the two are too tightly coupled, in that, people assume that if a ticket has been code reviewed, then it is as good as QA’d.

All of the points raised the developers raised during the code review can be associated with a specific file, class or function, yet there is little mention of the functionality from a wider context and how it would impact the user. This is where testing steps into the mix, and this is why a code review, should not replace testing.