Separately tracking software failures and faults

Question

I've recently finished reading a couple of Gerald Weinberg books on Quality Software Management. In them, he strongly recommends that organizations distinguish between software failures (which we would call bugs) and software faults, i.e. coding errors.

He also recommends than an organization keeps separately track of failures and faults, linking one or more of the former to one of the latter.

The specific terms he uses are System Trouble Incident for a failure report, and System Fault Analysis for the work that leads to the discovery of a fault.

I've searched for any further references to these terms on the internet but didn't find anything.

Does anyone work in an organization where failures and faults are recorded separately? And if yes, are there any tools out there that will let you do this seamlessly, and let you link failures to faults? Is it worth the trouble?

Answer 1

You could use TRAC. With TRAC, you can configure arbitrary ticket categories (bug, enhancement, cleanup...). You can also make one ticket depend from one another. So you could:

• Setup a "failure" and a "fault" category
• Use the "depends" feature to links failure to faults

Regarding the "worth the trouble" part of your question, I think the answer depends on the context. If your company/team is small enough, I don't think it is worth the trouble. In the other hand, if your structure is big enough that you have a separate support and engineering team, I think it's definitely worth having both:

• Support would enter "failures"
• Eng would enter "faults" and link them to "failures"

In the end, this helps better handling of the customer communication: instead of telling the client: "We fixed threading problem #123", you can say: "We fixed the crash #111 that you reported last week"