I may be expected to perform code reviews in what'll likely be Java. The thing is, I'm a software test engineer. I've never been a developer nor programmer. I've always thought another developer would be doing this sort of thing.

I have learned C, C++, Java, Perl, and concepts like OOP and design patterns in college (more than 10 years ago). I've picked up the fundamentals of Python and MySQL on my own recently. I may not be able to count on training for this, so what are some things I can do on my own to prepare for this? What else should I be aware of from a code review perspective?

  • Maybe you need to ask why they want you to review code. Particularly when implementing external interfaces, I (a developer) regularly ask one of our testers to do an informal testability review. In essence asking "Is there anything I can do to make this easier to test automatically?". It turns out I regularly overlook one or two things that testers would love to have exposed for autmation.
    – Daan
    Jan 10, 2015 at 15:07
  • Are you sure that there is not just a misunderstanding of what you're being asked to do? Paired testing makes sense but I don't see how you can add value in a code review if that isn't your field, other than asking QA related questions. Jan 13, 2015 at 8:17

5 Answers 5


When working in teams one of the most important added value of code-reviews is knowledge sharing. This leads me to think that other developers on the team should do the reviews and not testers who do not add code to the code-base.

I suggest you read the free (relative short) e-book "The best kept secrets of peer code review", its totally worth the read if you want to get into code-reviews. The main suggestion is that reviewers build a checklist to find common/high-risk mistakes. Afterwards monitor that those mistake become less and when they don't return remove them from the checklist. Start with a personal checklist and share it publicly.

As a tester you can help create and or use this (or other persons) checklist to check the code. Depending on your programming skills this might be something you could do.

enter image description here


My answer appears to fly in the face of the other answers so far. I think code reviews are a very valuable way to keep QA informed, and to understand what they are testing at a much lower level. Primarily for the same reason I think having code coverage results on manual and automated test passes are important, I think code reviews are also important.

It is not so much getting into the weeds with code reviews (although it can be as you become a more experienced developer), but more about pointing out differences at a high level in your understanding of acceptance criteria vs implementation, and also understanding how things work. You may find that 4 or 5 of your test scenarios are all handled under the hood by the same method in the code, which can help you determine if your tests are equivalent and even necessary. You may also find out that the way something was implemented was completely different than what you expected, and that can help direct your testing efforts to the right areas. You also get a chance to communicate with the developer directly and ask questions about risky areas, or discover code complexity that could lead to heavier testing of certain features.

In addition, there are plenty of things you can point out even with a very novice understanding of code, such as missing comments, extremely large functions that may need to be broken down into smaller digestible pieces, or duplicated or copied code that could be consolidated. You also may find that additional features or special handling of certain scenarios were added that were not outlined in the acceptance criteria and can then ask whether those things are acceptable.

Even without having a formal code review process for QA engineers, I have found it helpful to monitor check-ins just so I can keep up on what is being done, which can vary dramatically from what is actually spec'd out or part of user stories. It is amazing how often I find that developers have re-factored or modified something completely outside of the scope of changes for an iteration that I would have had no idea about except that I watch their check-ins. Sometimes, those re-factors have had defects. This is one way that many defects slip through to production without even being considered as a risk.

Finally, especially if a QA engineer is writing automation or other tools, code reviews of code from more senior developers is a great way to learn new things and increase your own understanding. I have re-used many many things in my own code over the years that I have discovered through code reviews of other's code.

  • 1
    I agree with your point of view. One more point to add is that the developer actually benefits from a code review because they often will find most of the issues themselves while they explain what the code does.
    – Peter
    Jan 9, 2015 at 18:58
  • 1
    Exactly, I have gone into reviews with this mindset, especially larger groups where I feel I have minimal input or impact. Otherwise, my position has been, if the Developer cannot explain to me simply what the code flow is through his code, he doesn't understand it enough to tell me that something might or might not be wrong. Asking "how does X happen in this function" is a good way to build up understand under the hood.
    – MichaelF
    Jan 9, 2015 at 20:51

As a fellow QA engineer, my advice to you is: don't. If you'll be reviewing code, you'll be partly responsible for the code's quality. But to do this task thoroughly, you need to have sufficient expertise and experience. Do you have a clear view on the framework, the legacy code? Do you know common best practices for Java programming? Are you up to date with the newest Java possibilities and perhaps new insights in OOP and such?

I'm guessing most of these answers are 'no'.

You might be in a position where you can't refuse, but you should address this issue with your manager anyway. Explain that solid code reviews can only be done, as you correctly assume, by developer peers, seniors preferably.

In short: code reviewing is none of a tester's business (unless, perhaps, test automation code). The exception being, of course, if you actually want to do this! But then ask yourself if you have enough knowledge to do the job properly.

It sounds like your management is trying to save resources one way or another, but such attitudes end up costing more in the long run.

  • Exactly. For non-Java-expert, reviewing the code might be a way to gain experience and exposure, learn proper usage of Java (which might be valid goal, ask your boss). If you are expected to detect mistakes in Java code, and have little experience detecting them (and no checklist, as suggested by @Niels van Reijmersdal, you will be wasting time which will be better spent doing manual testing, or writing automated tests. Jan 9, 2015 at 15:29

I support Frederik's answer that testers should not be involved in code reviews. But it is good for testers to be involved in other higher level reviews.

Testers should review the requirements and specifications to see whether they can be tested. There are many criteria that a tester might consider. A few of them are: Are the requirements and specifications clear enough and precise enough for test cases to be written? If not then how would the developers know what they should be making? How complex is the product and much effort will be needed to perform testing? Has the project management allocated sufficient time and resources to the testing? Are there features of the project that are complex or expensive to test but that add little value to the end user?


Try to sit with the developer who made the code and understand the concept. Then go review part by part to review and test and quality check it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.