How is code review different from QA (quality assurance) reviews?

Question

Can both be done at the same time? Besides the actual coder, who should participate? Should different people participate in one and not the other, or should it always be the the same participants in both? Just how should it be set-up between the two?

Answer 1

In my mind, Code Reviews are developer-centric. By this, I mean that developers review each others code to enforce best practices and good coding standards. Ideally, this should make sure that the code being checked into the application is at the highest quality. Whether or not this is done is a whole other story.

Quality Assurance is user-centric. I see QA as treating software as a blackbox - the code is irrelevant at this stage. QA should be evaluating various aspects of the application: usability, stress tests, requirements fulfillment, etc.

As to whether or not they can be done at the same time depends on the time of application that's being built. For example, applications could have automated tools running use case simulations every, say, hour on the most recent build. The problem with this, though, is that the use cases are locked into whatever has been coded or recorded. There's little variation. It continues to evaluate only whatever use cases and whatever behavior has been built into the simulation.

Additionally, it's usually the case that a testing department or QA department is in charge of the, ahem, QA of the application whereas the developers are in charge of the code reviews and, as such, the code quality.

Answer 2

Quality Assurance is a very wide subject and a code review would be part of it.

Now generally Q/A seems to be related to black box testing.

Answer 3

Code reviews are usually done around the time of unit testing, while QA testing takes places during functional testing after the code is deemed 'complete.'

Answer 4

Code Reviews are for the whole team to participate in. This makes it a great learning experience for your whole team. You can use these to bounce ideas off of each other and find the best way of doing something. I actually attend the code reviews at my company if I have the time free on my schedule and it in no way helps me with the QA process. I am there to learn and to help bounce ideas around.

Quality Assurance should have nothing to do with the code. I am currecntly a Software Quality Assurance Analyst with my company. In the QA process I do not need to see the code or have the code. I get the final application and test it at the application base. It is the DEVs responsiblility to test their code not mine. The QA process is for testing the software as it is going to be used in the real world by the end users.

Answer 5

Our code reviews include QA developers, so they hear discussions that point to different test equivalence classes. But the main focus in a code review or inspection is: Does the code perform as expected and does it meet our acceptance criteria and standards. So while it's a step in the quality process, it's not specifically a QA area, so typically there are more developers than QA folks in the room.

We've code-reviewed QA tests and output on projects I've worked on in the past, to make sure that the tests were doing what was expected and testing all the appropriate cases rather than varying data within the same equivalence class.

Answer 6

Code reviews focus on the code. A developer is looking on some piece of code, looking for possible issues, mistakes, or defects. Many times, concept like "beauty" and "smells" plays a central role during code reviews, because it is the gathering of people dedicated to creating code.

Quality assurance reviews focus on the risk. Each code change has a risk of issues - bugs, horrible user experience, data corruption. The internal working is only interesting as much as it sheds some light on possible risks, or mitigations.

It is very important, during QA reviews, to get as many different perspectives as possible; for this reason it may be useful to introduce also many of the people participating to the code review, but this is strictly not necessary.

Answer 7

OK, this is nit picking, but what most people call Quality Assurance (QA) is actually Quality Control (QC). QA is all about defect prevention, QC is all about defect detection.

Code review is a QC activity. Taking the results from a code review and improving your processes so that similar defects don't happen again would be QA.

That said, there are many ways of doing code reviews and at various levels of formality. Pair programming is like instant code review. Also having a trusted colleague or lead bench check your code before committing can be a code review. You can also have a more formal process that includes the coder, senior staff, CM, QC and QA. However you do it, it is usually done prior to delivering a build over for QC.

QC can either be black box (most common, doesn't need the code) or white box (testers inspect the code to look for possible ways of breaking it). It's generally not a good idea to have the people who wrote the code doing QC on it.

Answer 8

I agree with the answers posted so far, especially @Ironsides & @Tom.

I Googled "White Hat Black Hat QA Testing", and this SO Question was on the first page:

Developer testing vs. QA team testing - What is the right division of work?

Refer to the answers there for a good discussion of what belongs where.

On who should do what, during code reviews for one past employer we used the following roles:

• Presenter (not the author) - leads the code walkthrough
• Recorder (not the author) - records unanswered questions, action items, defects, etc for distribution
• Reviewers - at least one other developer who is not the author (so you have at least three sets of eyes)
• Author - answers questions.

Number one ground rule: Talk about the code (or the artifact under review) not the author.

Note also that a formal division of QA as described isn't the only way to approach the issue of QA. Small teams often use a combination of unit tests, continuous integration and users or user representatives during the development process. This allows the users or their representatives to get feedback into the process early and often, and can drastically reduce the need for a "Big Bang", exhaustive QA test when a release is made.