Audience
Testers, Developers, Managers
Key-Learnings
- Code review done by testers will increase collaboration and level of trust in the team
- Learn what information to look for in code review. Those information might uncover unidentified risks
- You don’t have to be a great programmer, because code review is for everyone, you just need to pay attention what to look for
Code review isn’t something testers are dealing with often. This is mainly due to popular belief that it should be reserved for developers, and that testers are not technical enough to add value to the process. However, when testers do code review, they should not review the same way developers do. They should consider what should be done from the tester’s perspective.
Testers should pay attention to the following:
- Comments
- Size of the change
- Structure of the change
- Unit tests – available or not?
- Timing of a change
- How it fits into the bigger picture by determining the risk and impact of a change on the system
In my experience comments usually contain a great amount of information. They tell us what has been done and, more importantly, what hasn’t. In terms of the size, sometimes a small change — a single line of code — might carry a great risk. Other times, we expect a small change and end up with dozens of files being updated. By looking at the comments and the size of a change, we can come up with additional ideas or questions that need to be discussed with developers in order to uncover any underlying risks.
By the end of this talk, I will explain the importance of code review for testers, why, how and when to do it and what kind of information to look for. When done right, code review for testers might uncover a wealth of important information influencing our testing. And if some parts of this information are missed and overlooked, it could result in risks not being addressed, shallow testing, and later problems affecting our end customers.