QA department is fairly new in our company and we are using TestTrack for defect tracking. I have few questions;
1. In TestTrack, we are using 1 field "PRIORITY" to define the priority and criticality of the defects. User has the option to choose from this field either;
1-Show Stopper (Highest)
2-Immediate Fix (High)
There seems to be no standards as to what defect qualify for the definition of the "PRIORITY". Everyone seems to have their own interpretation. Can someone out there suggest as to what should be the standard interpretation of the definitions of the "PRIORITY" of the defects?
2. In TestTrack, we are using 1 field "PRIORITY" to define the priority and criticality of the defects. I feel in order to define the granularity of the defects, there should be 2 fields to define the defect;
#1 field "Priority", where user should have the option from the drop down list to choose either "Show Stopper" or "Not a Show Stopper"
#2 field "Criticality", where user should have the option from the drop down list to choose either "Highest" or "High" or "Medium" or "Low"
I need to come up with the justification so we may have 2 fields instead of 1. Can any one reflect their views on this?
I will appreciate for all the help you may reflect on this.
My experience has been that if two fields are to be used, one is to rate the technical severity of the defect (crashes the system, feature doesnt work to spec, typo, etc.) and one to rate the severity as it relates to customer impact.
It's my experience that you could have a defect that crashes the application under test but is found in a rarely used feature and is difficult to reproduce. Due to the rare occurence the impact to the customer may be less than a usability defect, for example.
I won't give you an answer about what is right or wrong (that's for you to decide), but I can tell you how we have solved it.
We have an own-developed tool where the user have the possibility to select a priority-number between 1 (the application can't run anymore) to 5 (spelling issues or other defects that hardly affect the execution).
For us this means that priority also gives the hint about how fast the defect must be fixed. We don't treat priority and criticaly separately but I have full understanding for those who will treat it that way. It can be rather convinient to have one number for the impact of the system and one number for the priority due to fix the problem.
So it is really up to you to decide. Maybe it isn't worth the change in the tool ?
However, I don't think that you should use just a 2-level scale for criticaly.