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.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In "Applied Software Measurement" and "Code Complete" the authors state concrete numbers for removal efficiency of defects found during code reviews (formal, informal etc).

Is it common to track defects found during code reviews? What about informal reviews; I could imagine that it is quite difficult to persuade developers to store found bugs in a defect management system? How have you managed that so far?

Beside that, is it useful?

share|improve this question
up vote 5 down vote accepted

At my current workplace, we don't distinguish between different ways that bugs are discovered. If a developer expects the test team to test the bug fix, they log it. If they don't expect the test team to test it, they don't log it. They understand there actions have consequences, and so they make that decision carefully.

We never penalize anyone for logging bugs against their own code. We have worked places where that policy was different (or unstated), and in those circumstances some developers were afraid for anyone to log bugs against their code. You might consider what your organization's policy is and how it impacts organizational behavior.

share|improve this answer
How about advocacy of defects found this way? Do developers prefer you to verify them with tests or they are eager to fix them without any further confirmation? – dzieciou Jan 13 '13 at 19:14
It depends on the defect. If the code (or the change) is complicated, they are more likely to log a bug. But it's really up to them. – user246 Jan 13 '13 at 19:23
Thank you for your answer! What about Design Defects? Lets say one developer built in some code smells; so there is no functional defect, but it causes technical debt, as ,for example, this part of the system is harder to extend. – Roland Tiefenbrunner Jan 14 '13 at 21:38
You are getting into a grey area. Sometimes we log those bugs, and sometimes the developer just maintains a mental list. It is usually hard to predict which code will need to change six or twelve months from now. At some point it may be more useful to add "code smell" comments in the code than to log bugs. – user246 Jan 15 '13 at 1:07

I have personally found that the more you can reduce the overhead of developers fixing bugs before the code hits the main source branch the better off you are. I generally use a rule that as soon as a bug will be seen by or could effect someone else then it must be logged.

This allows testers and developers to pair together as part of a pre-checkin review and very quickly find and fix bugs very efficiently, without having to go through a bug triage and approval process.

The tradeoff is that you lose visibility of the issues being present in the code base in your metrics.

share|improve this answer

In my company some teams report problems found in code review using collaborative code review tools like Crucible. Those allow to share comments about the code inline and integrate easily with IDE.

Our architect sometimes send e-mails with code review results and they go through grooming and are included in the backlog of stories to do.

I, as a tester, try to avoid commenting pure technical debt. I rather report code review issues when they could result in breaking some functionality. Most issues are found during iteration, so I report them it in our iteration tracking/planning portal.

Regarding your question about usefulness, I had related question in the past: Is it fair to report a bug discovered during review without performing a test?, (which is rather about usefulness than fairness) and one of the main conclusions was that it might be more convincing to developers, if you confirm issue found in code review with a test

share|improve this answer
Thanks for the answer! Why do you try to avoid commenting pure technical debt? – Roland Tiefenbrunner Jan 14 '13 at 21:41
Because under time pressure we have more priority on functional defects. Unless we introduce something like Crucible, overhead on communicating technical debt issues is too big. Though, testers in our team are sometimes asked by developers to code review their work before commit. Then I take my chance to provide feedback if I see some "code smell". – dzieciou Jan 14 '13 at 21:56

Your Answer


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.