I have had quite a lot of discussions about code reviews. Quite many also with testers, by which I have understood that many do not do those.
I will not start arguing here on whether code reviews are good/important or not. But I will list a few things why I think testers would benefit of doing them.
1. Code is the only documentation that is up to date. If you really want to know how something really functions, you want to be able to see and read the code.
2. Knowing more about the thing done enables you to do better testing. You can spot things that you should definitely test, and things that you probably don't need to test that much. Like extra things added by coder, usage&modifications of existing functions, data types, etc.
And to arguments thinking that one loses their "independence" as a tester by knowing too much, I would worry a lot less about that than about testing stuff that you have no idea on how it has been built.
3. Improve logging. I obsess on logging. I am always asking to add more, more details, and in correct levels. Logs can help a ton when testing. Logs will be indispensable when tracking down those problems in production. Logs can help you analyse the usage, and non-usage of your system to spot further improvements.
If you are a tester and you are not obsessed on logs. Why?
4. Add testability. Logs are kind of a part of this already. But knowing how stuff has been built, can help you to ask for more control on some parts, or more visibility on others.
5. Read the unit tests. In my experience this is the most overlooked place when developers are doing the code reviews. And tests are something that testers should be pretty good at... Some examples be suggesting new tests, deleting of unnecessary tests, better input variables, and stronger assertions.
6. You might spot some other things too! Asking on unclear parts may reveal unnecessarily complex code OR you might learn something. Variable names can often be better. And occasionally one might even spot some functional issues too. But I would suggest to be quite careful when offering the feedback. Asking why something was done in this way is usually better, than telling how you think it should have been done.
Not doing them and still not convinced? It might not be for everybody, but based on my own experiences I do suggest at least trying it out a few times.
No access to the source control system? Ask and thou shall be given.
Can't read the code? Read it anyway. You will learn, and get better at it. And reading good code is a lot easier than writing it. Kind of like reading good books is easier than writing them.
Other team members think it is not useful for testers to do code reviews? Hard to think that this would be an actual issue.. But if it would be, ask them to read this post and to leave a comment telling why. If they will and I cannot counter comment - shame on me. If they won't - have a good time doing those code reviews!
Great input Anssi, I really like this overview. This is something that every tester should do. To add to point "can't read code" or understand the code something I think many testers not having a technical background fear. From my personal experience, developers will gladly explain the tests (unit/integraion/etc.) to you, and just be explaining the tests, many times they found that there were some issues with the tests which they quickly corrected. These issues would probably not been found unless they went through the tests and tried to explain what was done.
ReplyDeleteThanks for the comment Mili :)
ReplyDeleteAnd yes I have similar experiences, providing a little walkthrough of the diff is a nice practice to do. We did this quite extensively in my previous workplace where code reviews where pretty much mandatory (medical sw). And giving these walkthrough + doing the reviews right after the change was done + keeping the changes small made reviews run quite a lot smoother and provide more value too.
I would like to make the distinction tho that maybe this is not "something EVERY tester SHOULD do". There are a lot of different valuable roles that a tester may fill, which basically can take all of their time already and thus not leave the time to e.g. read the code.. but yea I think maybe this is something every tester could try, just to see if it works for them or not.