Ask Eileen

Welcome to Ask Eileen!

Eileen Boerger, President of Agilis Solutions answers your questions via this page or email to askeileen@agilissolutions.com

 Q & A:

Q: Should documentation defects be treated the same as other development defects?  It doesn’t seem intuitive to count typos the same as corrupt data, and it skews the metrics?

A:  I feel that all defects, no matter how minor, should be reported and tracked.  But, that doesn’t mean every defect should be treated the same.  I agree that documentation typos are not the same as software defects that corrupt data.  That’s why most defect tracking systems allow defects to be categorized according to their relative importance and allow for different levels of responses to the defects.  By categorizing defects properly in a defect tracking system, a software development team can determine how best to address the defects.  Defect reporting will take into account the relative importance of the defects and not report a typo as having the same impact as a defect that corrupts data.  However, it is important to understand that the management team (or their appointed delegate) has the final say as to which defects will be fixed prior to each release of the product, regardless of how they are reported in the defect tracking system.  

The most effective method I’ve worked with for categorizing defects allows for two basic types of defect categories.  I will call these categories “severity” and “priority”.  Each category is then broken into 4 levels (in this example, 1 is the highest, 4 the lowest).

Defect “severity” has to do with the impact the defect has on the running software.  An example of a severity level 1 defect would be the software crashes or corrupts data, and the defect has no workaround.  A severity level 2 defect could be a level 1 defect with a workaround.  A severity level 4 defect usually has no impact on the running of the software, but should eventually be fixed (like a typo).

Defect “priority” has to do with the impact to the customer reporting the defect.  An example of a level 1 priority defect would represent the customer having to stop work due to the defect.  The other levels usually mean the customer can continue to work, but something is wrong.  A level 4 priority defect usually means the customer has spotted something that has no impact on them, but should be fixed eventually.

Interestingly enough, a level 1 severity defect may not be a level 1 priority defect if a customer never runs into the problem.  And the opposite can happen, a customer may report a level 1 priority defect that is not a level 1 severity defect due to the effect of the software to their business.  That’s why it’s important to use the two categories of defects.

If you have a question for Eileen, please submit below