Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
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 Jun 9 '11 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 Jun 9 '11 at 17:13
add comment

11 Answers

up vote 28 down vote accepted

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.

share|improve this answer
    
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 Jun 9 '11 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. –  TristaanOgre Jun 10 '11 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 Dec 2 '12 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 Dec 2 '12 at 17:02
    
@dzieciou - it was mostly learning curve - it took a while before testers could find issues with regularity. –  Alan Dec 3 '12 at 7:59
add comment

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
share|improve this answer
    
+1 for the sync up points. –  Suchit Parikh Jun 9 '11 at 22:20
    
And we all know the earlier we find a bug, the cheaper it is to fix! –  DuncN Jul 22 '11 at 21:26
add comment

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.

share|improve this answer
    
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 Jul 22 '11 at 17:52
add comment

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.

share|improve this answer
1  
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 Jul 21 '11 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 Jul 22 '11 at 21:27
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
    
+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 Dec 4 '12 at 18:08
add comment

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)
share|improve this answer
    
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 Dec 4 '12 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 Dec 4 '12 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 Dec 4 '12 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 Dec 4 '12 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 Dec 4 '12 at 18:04
show 4 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 Jun 10 '11 at 20:31
    
@corsiKa, can you give an example of how this makes "things worse in the long run"? –  dzieciou Dec 5 '12 at 7:55
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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