Abstract: 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 highly 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.
Learning Outcomes: - Demonstrate that the value of peer review is far broader than simply code structure/layout/performance
- Show how existing peer review approaches fail to promote collaboration or incorporate the experience of QA, to the detriment of the product
- Explain how QA involvement in peer review can lead to better, risk-based decisions on additional test activities
- Define a modified peer review process based on clear, role-specific guidance for reviewers and enumerate the benefits it offers, such as improved code readability and better collaboration within the team
- Propose a revised Definition of Done, incorporating the modified peer review process
Attachments:
