Skip to main content

Six reasons why testers should do code reviews


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!



Comments

  1. 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.

    ReplyDelete
  2. Thanks for the comment Mili :)

    And 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.

    ReplyDelete

Post a Comment

Popular posts from this blog

I don't report bugs

I don't report bugs . Bug is such a loaded word that people understand very differently, that instead of using it and explaining what I mean by it I rather just use other words. Like observations, thoughts, surprises, ideas, alternatives, or something similar. (And no I don't use fault, defect, or error either). Bug has also quite a negative connotation. "Reporting a bug" is kind of like telling someone that they've been served. And as we are actually giving away the gift of information, why wrap it in such a nasty package? And maybe more importantly it is very likely that whatever you might have to say is wrong. If not plain wrong, then at least incomplete. So I like to approach the kind of situations with the assumption that I am probably wrong. Cutting off anything that might sound arrogant makes stuff quite a lot easier. Especially after you realise later on that you have been wrong. I leave plenty of observations unreported . I don't want to waste

Testing drunk

(My first blog writing ever.) I've been thinking a long time that it's funny how many bugs I find by accident. Try to do something, make a mistake and boom - a bug is found.  Making the mistakes intentionally doesn't quite work - that's why they are called accidents I guess.. So I've thought of ways to make myself more prone to accidents, coming up with an apparent one; testing drunk. TUI (testing under the influence). So this I gotta try. More to come on that later.

Testers of past be the IT stars of the future?

Been noticing two a bit conflicting themes lately. 1. Testers getting (or pushed) to be more technical and write test automation code 2. Articles listing future IT core skills as widely non-technical So whereas many testers are moving to work more on test automation, the vital skills of the future may be such as: - Creativity -  Analytical (critical) thinking  -  Activ e  learning  with a growth mindset   -  Judgment and decision making -  Interpersonal communication skills - Complex Problem Solving Which sounds almost like a list of vital skills needed for an exploratory tester.  So we should perhaps remind the ones starting a testing career or moving away from it, that also these skills are something that can be quite valuable in the future as well. Maybe even the most valuable.