Be the first to like this
Peer review can be a major contributor to code quality, but the practice is usually ill-defined and excludes some team members who can make a huge difference - those whose focus is testing.
The orthodox reasoning is that, if someone doesn't have development expertise, then they will not have anything to contribute to a code review. This is wrong on several levels. Software should be easy to read, logically structured, with clear, comprehensible names - and the people who are best placed to notice when it isn't are those who won't focus on syntax and coding style.
As well as contributing to the readability of the code, testers will gain early insight into areas of complexity or confusion, which is invaluable when making risk-based judgements about where additional testing is needed, whether automated, scripted, or exploratory.
In this interactive session, we'll explore how and why team members with testing 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 concrete next steps, including a structured description of an inclusive peer-review process and a modified Definition of Done.
The focus of peer reviews is frequently limited to code structure and conformance to coding standards not enforced by static inspection tools. The documentary value of the code (and specifically the unit tests) is frequently ignored, as is the need to communicate the extent of developer testing to their colleagues whose focus is on testing.