Does anyone know of a good bug matrix or defect management process?

Question

I am currently looking for a good bug matrix. Does anyone know of one, i have come across this: https://michaellant.com/2010/05/25/a-simple-agile-defect-management-process/

Answer 1

Matrix you mentioned in your link calls Scope what is usually called Visibility or Impact. Otherwise it is the same, Severity is mixture of Impact and Vulnerability.

I see no additional value in mixing into some matrix Severity and Priority as the Michael Lant in his article does, as both metrics tells little different story and therefore I consider it WRONG. You can have bugs which are just cosmetic with minor occurence to users, but extremely important for another reason (presence of the fix in next build, key user, etc.)

Priority should not be determined directly from severity/impact/vulnerability metrics as then it can become useless.

• Severity tells you how severe the fault is, what is the damage and how many users will see that.
• Priority tells you how qick the fault should be fixed (usually stakeholder's wish).

Look on my answered questions which was created in early beta to provide some content to SQAStackExchange:

• How to categorize defects? - especially Ivor McCormack's matrix for Severity from (Vulnerability and Impact) and mine response about the ISTQB standards.
• What is the difference between bug severity and bug priority? - for the difference between Severity and Priority - accepted solution is the best.

Answer 2

I recommend not using a bug matrix for two reasons:

• this more subjective than you might think
• fails at tying the defect to the actual impact to the customer

I recommend writing a good quality story instead. Of course, if you don't have anything else and are just looking for ways to prioritize bug fixes ... and what doesn't get fixed ... then I might actually agree with the faulty argument that it's better than nothing.

I attempted to give a more defined response here at StackExchange, but I haven't learned the ins and outs of not being classified spam. My detailed version is here if you want the nitty-gritty on why it's subjective, why it fails at this task and some suggestions on the alternative.

Answer 3

I am a big advocate of the "zero defect policy" and how it classifies defects. Its so much easier to fix defects just after they have been introduced.

Agile teams should learn as soon as possible from their feedback. Defects are also feedback, use it to-do a root-cause analyse after fixing any defect. This helps to figure out how to prevent something similar happening in the future.

I have added a fifth classification "Closed" for defects that should never get priority, because they are to trivial. Make sure you communicate clearly and fair to your reporters.