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?

3 Answers 3


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.

  • 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, 2013 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, 2013 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. Jan 14, 2013 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, 2013 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.


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

  • Thanks for the answer! Why do you try to avoid commenting pure technical debt? Jan 14, 2013 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, 2013 at 21:56

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.