Are code reviews considered part of QA?

Question

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?

Answer 1

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.

Answer 2

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
   

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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)

Answer 10

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.

Answer 11

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.