XP 2018

A lot of software sucks. It’s poorly documented and unmaintainable. New team members take ages to get up to speed and the support team struggle to understand it. The maintenance and enhancement costs increase over time and, sooner or later, someone suggests a rewrite.

There are a lot of reasons why this happens, but one of them is the industry’s poor approach to code-review/peer-review. When peer-reviews are conducted solely by developers, the focus is on those aspects that are of most interest to them. The documentary aspect of unit tests, the ease of on-boarding new team members, and the impact on those tasked with QA are often ignored.

The inclusion of team members that have QA expertise can go a long way to improving this situation, ESPECIALLY if they don’t have development experience. As well as ensuring that unit tests adequately document the behaviour of the code, it also enables QA to make good, risk-based judgements about which areas of the code are most in need of additional testing, whether manual, automated or exploratory.
 
In this highly interactive session, we’ll explore how and why team members with QA expertise should participate in the peer-review of development commits. We’ll dig into the positive impact this has on our products, our processes and our people. You’ll leave with an actionable list of improvements including a structured description of an inclusive peer-review process and a modified Definition of Done.