2

Our QA team is not a large one, but consists of full or partially remote, full or part time team members which, as it currently stands, live in different countries and in different timezones.

We are trying to review each other's code, sending pull requests and mention each other as reviewers with me being the end person to merge (unless it is not mine pull request, of course). Ideally, we try to have multiple approves from reviewers, but because most of us are part-time and moreover remote, timing does not work in our favor.

This leads to feedback loop being really slow - for instance, one person might ask for this improvement, other, in a couple of hours, might ask for another one. Then, the author of the PR would address the comments, but then one more person arrives and suggests some other improvements.

What would you recommend to improve in this process? Can this idea of having multiple approves from different distributed part-time reviewers work?

1

The main purpose of code review is learning (yes, cross-validation/static testing is secondary).

Considering there no significative difference of knowledge of different parts of the application between the sub-teams:

You could use code review as a static testing tool within the locals teams (increasing feedback speed) and as a learning tool for the remote teams (someone from the remote team reading merged PR, for learning). If the remote counter-part detect a opportunity for refactoring, it can be done after the merging.

The challenge is to create this culture of learning through code review (even merged ones).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.