Bug Classification in ImpressCMS
Posted by skenow on 1259463721
I've searched through the forums, wiki and email archives for discussions we may have had about our bug severities and I put together the following. What we'll work through in this post is the severities we use, the generally accepted definitions of those severities outside of ImpressCMS and how we might make specific clarifications to them.
We are using a 5-level severity classification system: Critical (highest), Blocker, Major, MInor, Trivial (lowest). Here are the general definitions of these levels.
Blocker
Defects that could (or did) cause disastrous consequences for the system in question. There is no workaround. Issues of this type will be immediately addressed and a new release will result.
Example - critical loss of data, critical loss of system availability, critical loss of security, etc.
Critical
Defects that could (or did) cause very serious consequences for the system in question. Issues of this type will be immediately addressed and a new release will result
Example - A function is severely broken, cannot be used and there is no workaround.
Major
Defects that could (or did) cause significant consequences for the system in question - A defect that needs to be fixed but there is a workaround. Issues of this type will be addressed in the next or a future regular release.
Example 1 - losing data from a serial device during heavy loads.
Example 2 - Function badly broken but workaround exists
Minor
Defects that could (or did) cause small or negligible consequences for the system in question. Easy to recover or workaround. Issues of this type will be addressed in a future regular release.
Example 1 - Error messages misleading.
Example 2 - Displaying output in a font or format other than what the customer desired.
Trivial
Trivial defects that can cause no negative consequences for the system in question. Such defects normally produce no erroneous outputs. Issues of this type may be addressed in a future regular release.
Example 1 - simple typos in documentation.
Example 2 - bad layout or mis-spelling on screen.
We are using a 5-level severity classification system: Critical (highest), Blocker, Major, MInor, Trivial (lowest). Here are the general definitions of these levels.
Blocker
Defects that could (or did) cause disastrous consequences for the system in question. There is no workaround. Issues of this type will be immediately addressed and a new release will result.
Example - critical loss of data, critical loss of system availability, critical loss of security, etc.
Critical
Defects that could (or did) cause very serious consequences for the system in question. Issues of this type will be immediately addressed and a new release will result
Example - A function is severely broken, cannot be used and there is no workaround.
Major
Defects that could (or did) cause significant consequences for the system in question - A defect that needs to be fixed but there is a workaround. Issues of this type will be addressed in the next or a future regular release.
Example 1 - losing data from a serial device during heavy loads.
Example 2 - Function badly broken but workaround exists
Minor
Defects that could (or did) cause small or negligible consequences for the system in question. Easy to recover or workaround. Issues of this type will be addressed in a future regular release.
Example 1 - Error messages misleading.
Example 2 - Displaying output in a font or format other than what the customer desired.
Trivial
Trivial defects that can cause no negative consequences for the system in question. Such defects normally produce no erroneous outputs. Issues of this type may be addressed in a future regular release.
Example 1 - simple typos in documentation.
Example 2 - bad layout or mis-spelling on screen.
This Post was from: https://www.impresscms.org/iforum/viewtopic.php?topic_id=3833&post_id=34720