Code review isn’t something testers discuss often. This is mainly due to popular belief that it should be reserved for developers and testers are not technical enough to add value to the process. However, when talking about code review for testers, we’re not talking about the “regular” code review developers perform — that should stay reserved for them. Code review for testers considers what should be done from the tester’s perspective once developers are done reviewing the change.
Once testers start looking at the change, they should pay attention to the following:
– Size of the change
– Structure of the change
– Timing of a change
– How it fits into the bigger picture
Comments usually contain the greatest 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. The structure of the change might tell us if there’s something extra present there that we haven’t expected, or if there’s anything that is missing. It also tells us whether everything is unit tested as agreed, if there are any unit tests at all, and so on. Each change doesn’t exist on its own — it is a part of something bigger than itself and needs to get along nicely with other changes.
By the end of this talk, I hope to encourage you to start performing regular code review sessions within your team. Each change on the project — no matter the size — presents a wealth of important information. 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.