I was having a discussion with a fellow developer and we were talking about QA practices. I was thinking that code review would be a QA practice because you're not making anything, but rather are inspecting it. He said it's part of the development process because it deals directly with the code, not just functionality or abstract concepts.

I can see his point of view, and now it has me thinking: code reviews are PEER reviews - they should be done by other developers (or at the very least, someone with significant development experience.) So I could easily see how it would be classified as part of the development process.

If I had two teams, a development team and a QA team, would it be appropriate to have the QA team do code reviews instead of the development team? Or perhaps in addition to the development team? Does it differ from firm to firm? Is it just a matter of semantics?

  • 3
    Can you describe what you mean when you say something is or isn't part of QA? Are you asking about organizational boundaries, or categories of work that someone should be capable of doing, or something else?
    – user246
    Commented Jun 9, 2011 at 17:05
  • @user246 I clarified my summary. If there were two teams, a dev and QA team, would it be appropriate for the QA team to do code reviews instead of the dev team? Or would it be something the dev team should do, even if it is something that contributes to the concept of "Quality Assurance."
    – corsiKa
    Commented Jun 9, 2011 at 17:13

11 Answers 11


Anyone can perform code reviews. In my experience, I've found big benefits in having both dev and test perform code reviews - testers tend to look at code differently than developers (just as they look at functionality and features with a slightly different lens.

At a higher level, software creation is a collaborative process - I suggest worrying less about who does what, and more about how the work gets done.

I wrote a paper about my test team's experiences with code reviews here.

  • I'm reading this paper between queries at work here, and I really like it - I especially like the idea of not reviewing everything, and that intuition is part of the decision criteria for review! Any time you can inject common (or uncommon!) sense into the process, it's a win.
    – corsiKa
    Commented Jun 9, 2011 at 19:38
  • I'm with @glow on this. EXCELLENT paper. I've shared the paper around the office here and sent it back to my previous place of employment as well. Commented Jun 10, 2011 at 18:36
  • @Alan, in the paper your write "[...] we didn’t find many bugs in the initial steps". Why was so? Have number of bugs increased? Have testers found bugs that developers had not tended to find?
    – dzieciou
    Commented Dec 2, 2012 at 16:48
  • From the checklist in appendix I can that during code review testers are not only looking for bugs but also for technical debt issues.
    – dzieciou
    Commented Dec 2, 2012 at 17:02
  • @dzieciou - it was mostly learning curve - it took a while before testers could find issues with regularity.
    – Alan
    Commented Dec 3, 2012 at 7:59

Code review belongs to the Static Testing category which is very much a part of QA activities. It is the only available method that enables early finding of bugs in the SDLC. It evaluates the sanity of the code and algorithm without any actual execution on the computer and hence the name "Static" testing.

I believe that it would be highly profitable to the organization if the QA syncs up with the DEV in the below review activities:

  1. Requirements review
  2. Feasibility review
  3. Review screen layout against standards
  4. Analyze program’s control and data flow
  5. Existential check of the features expected as a part of the product
  • And we all know the earlier we find a bug, the cheaper it is to fix!
    – DuncN
    Commented Jul 22, 2011 at 21:26

QA (Quality Assurance) is a buzzword that, depending upon your environment could mean multiple things. In some sites, QA is equivalent to the software testers and their duties. In sites with this usage of QA, then no, code reviews are not part of the QA process because they are executed by developers against developer code and does not involve the software testing group.

In other sites, QA is a group that is separate from both developers and software testers as a group that over-sees all parts of the development process that are put in place to manage and assure a quality product. In this case, code reviews are a QA process because the QA group monitors and makes sure that code reviews are executed at the appropriate time. They do not do the code reviews themselves, but it is a QA task that is executed by developers to satisfy QA criteria for the SDLC.

  • 2
    I disagree that QA is a buzzword. It has a very specific meaning and scope. However, most departments or individuals that claim to be responsible for QA, aren't fulfilling the definition of Quality Assurance.
    – Jim Rush
    Commented Jul 21, 2011 at 21:37
  • @Jim Rush - agreed. I test software. I don't know enough of external factors impacting the quality of a product in order to comment on it.
    – DuncN
    Commented Jul 22, 2011 at 21:27

I've had this conversation with numerous developers, testers, and managers. You are right when you say that code reviews are actually PEER reviews. I personally consider these primarily a developer activity (the same reason why I often share my test strategies and cases with other testers before the rest of the team). In my own experience however, the peer review tends to be part of the entrance criteria before being promoted to a test environment.

This being said, there is considerable benefit to having a tester/QA Analyst available during the code review. We aren't constantly looking at the code itself and can sometimes ask why a piece of code was written one way and not another (also a great learning experience for us). This is also a great time to have someone maybe point out some business logic that the developer may wasn't aware of or didn't think of. It's easier for everyone if more bugs are caught at this stage.

In addition to all of this though, I second Alan's response about software development being a collaborative effort. Don't limit yourself to only developers or QA's. If there's a BA/PM/UAT/anyone else who could understand parts of the code an maybe have some good input, don't exclude them, but don't make it so large that it can't be done relatively quickly.


Code reviews are clearly a kind of QA, virtually by definition. However, often QA is compartmentalized separately from development, and uses bug tracking and test tracking software and methodologies to scope and assess their process. The great thing about code review is that it happens in the development cycle, and typically, any bugs or other issues discovered are corrected as part of the development process, and not tracked as bugs or tested as fixed in the QA cycle. This averts the overhead of problems propagating into the next phase of product development, which saves time and money and also improves quality (the latter because defects found during code review aren't necessarily found in testing). The same philosophy of doing QA at all so that problems aren't found in the field, which is costly in terms of customer satisfaction, re-releasing of fixes, etc., can equally be applied to doing code reviews and fixing defects during development that otherwise would be found later in the overall product development process.

Whether or not to include QA people in a code review really depends on what is being reviewed. Obviously if it's code being reviewed and they're not programmers, it probably wouldn't make much sense. But are these unit tests, which might have some bearing on testing? Or, it could be useful to have someone coming from a black box standpoint looking over the code. There is such a diversity of types of code and other non-code documents that can be reviewed, and diversity of development environments and products being developed, that there isn't one correct answer to this question. It's best to just try new approaches and heuristically determine what works best for your development process.

  • I like this article: it's important to make the distinction between development code and test code (even if they're both written by developers.) +1
    – corsiKa
    Commented Jul 22, 2011 at 17:52

It depends on the organization. There are some conditions that need to be met in order for a code review to be effective. Obviously, the reviewer needs to be skillful at reading code and identifying potential problems. Less obvious but just as important, the reviewer and the developer need to have a rapport that fosters constructive criticism. If those conditions are not met, a code review could be a waste of time, or even worse, a destructive process that damages working relationships. The constructive pairing of a reviewer with a developer might be within the dev group or between QA and dev; it just depends on the organization and the individuals.

  • Insufficient rapport between developer and reviewer may be an indicator of deeper organizational and/or cultural issues that may need to be addressed before worrying about where the review responsibility rests. Commented Oct 13, 2021 at 14:47

I think we will have considerable benefit if QA team is technically sound. I am quoting from my experience.

Testing the system as black box - You will be focussing on user scenarios, covering maximum end user scenarios

By knowing the implementation details / methods - I was able to focus more on logging aspects, how the system works, where it can possibly fail. With a mix of black box and some white box testing would be a right mix

QA team may not review coding guidelines or provide technical suggestions but they can definetely raise the point - How does the system behave in this particular scenario ? Will failure be logged for this particular scenario ? How does retry logic work here ?

If not code review I would atleast expect QA team to be part of design reviews


Theoretically, it depends on the ability of the individual QA. If the QA reviewing the code has the ability to test the application without any bias created by his/her detailed knowledge of the implementation, great!

Realistically, if the QA is reviewing the code, he/she is looking at the implementation details. Too much knowledge of how the code is implemented can create a strong bias. One of the strengths of a QA is the ability to combine the knowledge of business and technology and see if there is a good balance achieved. An equivalent question may be 'Should QA be part of the team that defines business requirements?'

I have been a part of both the environments, and personally feel code review is better not the part of QA.

  • +1 For describing downside of code-reviewing by testers. The solution is to pay only a half of this price. Have testers that do code reviews and those who do only black-box testing.
    – dzieciou
    Commented Dec 4, 2012 at 18:08

Getting as close as possible to your question "Are code reviews considered part of QA?", I guess you're trying to identify what team (QA vs Dev) should be responsible for "code reviews". In my opinion both of them should take care of that issue, but QA should manage the situation.

  • Code review, either as part of a "peer programming" experience or just as part of the programmer tasks, is definitely a development activity. It is a manual process related with the programming of the functionality requested. It's done over the new/modifed source code, so it has a limited scope during the process. In any case you (QA) don't have any evidence of the work done (reviewed code? results?)
  • Static Code analysis - full application source code - should be under QA area, as far as this team should be responsible of getting measurements on metrics and monitoring the programming standards compliance. As a result, QA team should produce an action plan for the improvement of metrics and the mitigation of detected violations (next releases development input)

This is fully compatible with having the static code analysis integrated with the development environment (continuos integration, for instance). But QA having the lead role to guide the development team:

  • to produce and to prioritize the action plan
  • to define the quality model
  • to manage the quality gate (software certification)
  • 1
    Welcome to SQA... I'm not convinced by your suggestion that SCA should be under QA - IMHO, SCA should be done by the developers, with the objective of minimising the number of violations BEFORE RELEASE rather than as a second iteration.
    – Andrew
    Commented Dec 4, 2012 at 13:40
  • There is no conflict at all with that proposal. I mean, of course developers should minimise violations before release... who's responsible for accepting/rejecting a release? A mean, a SQA team should analyze several metrics: test results, violations reports...
    – erDave
    Commented Dec 4, 2012 at 14:32
  • Bytheway...Thanks for the wellcome :) Just to point out, it is important to clarify what we understand when we are talking about a SQA team... I'm not pointing to the "testers", but the guys in charge of analyze the test results, and analysis code results in order to decide if the delivered software should be released
    – erDave
    Commented Dec 4, 2012 at 14:56
  • @erDave, regarding clarification: What do you mean by "Static Code analysis" here? What do you mean by "full application source code"?
    – dzieciou
    Commented Dec 4, 2012 at 18:03
  • @erDave: I also do not quite understand how QA defined action plan for static analysis results. Can you give an example of that?
    – dzieciou
    Commented Dec 4, 2012 at 18:04

Often the answer can only be - It depends...

The term "Code Review" itself is a broad brush. It can include the fairly simple "Does this code smell?" check all the way to a highly detailed analysis of a hard real time system? It could even be an architectural review by another name.

It will also depend on the ego's in the teams. Some developers would consider it a supreme insult that a QA should review their code, whilst there are some QA's out there who while amazing at their role would run away at the sight of a try-catch block.

However after all that equivocating, yes there is a role for QA and others to be involved in a "code review". I would certainly advocate QA's / Testers get involved with reviewing the unit tests. Some developers need more help in this area than others. By helping them understand unit testing and write better tests you help yourself as well.


I've been in places where QA did not participate in code reviews, and in some where QA did participate, in many places there were different goals that were being achieved. Some were like code reviews where we looked over the code and brought up questions, queries as to how things were coded. In a few we also had Code Walkthroughs in addition, this also have the Developers the extra task of explaining their thinking in how code was done, this brought up questions from both Developers and QA that some developers said would never have come up in a general peer review; at least in that environment.

Some of the reviews did not always get comments from QA, but at the very least it did give some a better understanding of how things were working behind the scenes. More information and understanding is never a bad thing.

  • Unfortunately that last sentence is not always true. Our business analysts have full access to the database tables and their layouts, and are permitted to dictate what goes where. Now, if they had even MORE information and understanding, it would be very nice, but they don't so they end up with just enough information to think they know what's going on and end up making things worse in the long run.
    – corsiKa
    Commented Jun 10, 2011 at 20:31
  • @corsiKa, can you give an example of how this makes "things worse in the long run"?
    – dzieciou
    Commented Dec 5, 2012 at 7:55

Your Answer

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

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