16

I was thinking of tagging resolved cases by their (probable) cause, e.g.

  • incomplete feature specification
  • last-minute fix after test
  • typo
  • ...

Maybe common causes might show up in this, so we get feedback and take precise steps to prevent these. Or maybe this is just a futile exercise in statistics and blame circulation.

What do you think?

More general, what kind of analysis do you run on your issue tracker? What other information besides "what should I do today?" and "can we deliver?" do you get out of it?

Improve this question

7 Answers 7

Reset to default
14

The best solution I've seen to this is in enterprise-level bug-tracking. They try to assess and determine the root cause of the bug. Not the person, but the actual root cause. Examples of this might be:

  • Didn't follow the coding conventions
  • Bad coding logic
  • Fix for another bug broke this bug
  • Third-party library's bug
  • etc.

Finger-pointing is not useful, and even if done, we didn't put much stock in it. Everybody makes mistakes. It's more important to see what mistakes are being repeated, so that we can fix them. For the root causes listed above, the solutions might be (in order):

  • Create a convention that will prevent the bug, and enforce it via code-reviews
  • Fix the logic
  • Put in unit testing to prevent regressions
  • Trade one third-party library for a less buggy one
  • etc.
Improve this answer
4
  • +1 for tracking the root cause. "Jeff screwed up" is not the kind of thing you want to track in the bug log :)
    – Marcie
    Mar 4, 2011 at 17:23
  • 3
    While we might care if Jeff screwed up, more often, we just care that the product was screwed up and needs to be fixed. Unless Jeff is causing 80% of our bugs; then we care :)
    – ashes999
    Mar 4, 2011 at 18:52
  • +1. There should be a root cause analysis team for frequent and similar bugs. They will find the root cause and update company's knowledge base.
    – Sandeep Kumar M
    Mar 5, 2011 at 3:54
  • We had defects meeting, which were similar to the sprint review from Scrum, where we showed the how a defect appeared, how was it investigated and resolved, and we also showed the tricks we used. The purpose was to share knowledge/tricks among teams
    – Zsolt
    Jan 23, 2012 at 8:46
5

+1 to ashes999 for focusing on the root cause, but characterizations like:

  • Didn't follow the coding conventions
  • Bad coding logic
  • Fix for another bug broke this bug
  • Third-party library's bug

Tend to be so specific that over time, you have too many categories to be helpful. On some projects (but not all) I have categorized bugs by Phase - sort of a loose term to try to capture when in your project life cycle the defect was injected.

Having a drop down box allowing you to select from Requirements, Design, Code, Integration is all I have ever needed. If you are really hardcore you could split this into 2 parts: Phase Injected and Phase Detected. The basic idea here is defect phase containment - there is some good evidence that shows that the longer it takes you to find a defect, the more expensive it is to fix. For example, a requirements error is cheap to resolve in the while you are working on your requirements, but may cost plenty after you've released your product.

Even if you don't do all the fancy level 5 CMMI analysis, knowing what phase you are injecting problems in is extremely helpful. Like any other measurement, you should create it with a specific goal in mind - knowing that most of your defects are ultimately related to requirements or design or coding or whatever helps focus you attention on where the process fix should be. Otherwise, you may be tempted to add more and more testing. This is potentially the least efficient way to address the problem.

See also:

Improve this answer
2

I agree that blame is to be avoided if you want an open working environment. What you should concentrate on is what area it happened in, and in what part of the lifecycle it was introduced:

Are there areas of code that keep getting bugs? Are they especially sensitive to changes because of over complexity? Should these areas have more unit tests and/or stricter release management (or even a rewrite)?

Are bugs consistently being introduced at the end of the project? This can be an indicator of too many late requirement changes. Bugs evenly distributed throughout the main development stage can be helped by performing peer code reviews.

Even if issues are arising because of a person, concentrating on adding countermeasures to what they're working on rather than them will allow you to mitigate problems without causing personal issues.

Improve this answer
2

I believe tracking of the root cause of bugs is quite important, even more so if the root cause turns out to be something systematic like part of your development process.

For example, the analysis shows that the code that deals with the integration of a deliverable from an outsourced company is consistently broken and the root cause is that the requirements specifications were not well understood and controlled. This is a systematic problem and needs to be addressed so that future impact is minimised.

We tend to track the root causes of the defect and the area which the solutions are applied.

Improve this answer
1

Definitely don't think this is an exercise in apportioning blame, but a process which enables a greater understanding of what the main causes of issues were within the project. It's up to the project manager to maintain a non-blame culture within the project boundaries.

Or maybe this is just a futile exercise in statistics

The statistics will substantiate the key problem areas. This will assist in the post implementation reviews, and identify what lessons can be learned for future projects or even benefit other projects that are currently running.

Improve this answer
1

The cause of bug is a very important metric. I generally name is as "Resolved As" with values: Code Fix, Environment Issue, External Entity, Bad Data, Design Gap etc.

There is no blame game here as only the team lead should be allowed to categorize it. QA and Devs should not be setting the Cause.

End of the day it is useful to know that environment has caused 60% of the issues and bad data in the database cause another 20%, while only 10% are related to code. By this means we know we need to focus more on the environment and deployment in our next project. Behind the scene, it can also help in measuring the KPI accurately.

Improve this answer
0

Of course, "blame" should have nothing to do with it. We are all engaged in an extremely complex human endeavor, and no one should ever be "blamed." We need to remain focused on the process, not the people who engage in it. The only goal should be to learn how to do it better – and this is actually a very "situation-specific" goal, not a general one.

It is very useful to track what we think the root-cause was, and exactly where in the process it might have happened. (See the "containment" answer above.) Was it genuinely that "someone made a mistake," or is it actually a sign of something else? It might not be 'a bug!'

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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