Surprisingly,
defect priority should not be set by QA. QA are generally the owners of the defect tracking system and control it, but this is one attribute that they should not control. The defect tracker is a shared resource between QA, engineering, engineering management, and product mangement and is a coordinating mechanism for all these parties.
Commonly people mix up
priority and
severity, for example, there may be a severe defect that causes the software either not to install or to cease functioning.
It is common for new releases to have various
installation problems when they first get to QA. This blocks QA, so they mark the defects with a high severity and high priority. This issue has a high severity and needs to be addressed right away, but remember bug tracking systems are append only -- once this defect gets into the system, it will never get out. This kind of issue should be escalated to the engineers and engineering management because it makes little sense to clog the defect tracking system with it.
Now there may be
intermittent issues that cause the software to fail and you may assume that this defect would be high priority, but if it occurs very rarely and would cost too much to fix then this defect may be a low priority. Once again the priority of an intermittent severe issue can not be determined by QA.
Similarly, there may be many cosmetic or minor defects where fixing them might make a huge difference in the user experience and reduce support calls. Even though these defects are minor, they may be
easy to fix and save you serious money. Once again, this can not be decided by QA.
Therefore, QA should reserve the right to set the initial severity, and may have an internal field for QA priority, but the priority of a defect should be determined by a
product manager (PM) who has a more complete understanding of the overall context of the product. The priority of a defect is a business issue, not an engineering or QA issue.
Ideally, the product manger will set the priority of a defect during a
defect triage session where representatives from engineering, engineering management, and QA are present. As you go through each new defect each person can present their logic for what the priority should be. The PM should then set the priority defect and assign the release it should be fixed in (i.e. this release, minor release, major release, won't fix). Ideally there are extra fields in the defect record for both QA and development to put their priority beliefs.
It is important that the main status field of a defect not include any of the following or your
defect tracker will go to hell (i.e. this information should be in other fields):
- Priority
- Severity
- Fix version
It is very hard to generate meaningful reports when these attributes creep into the defect status. This has happened if you have a multi-page training manual for entering defects into the system. Some of the statuses that make sense initially but turn the defect system into a nightmare are:
- FAD (functions as designed)
- WontFix
- NextVersion
- CantReproduce
Of course, if you don't have regular bug triage sessions with all the parties mentioned above then you are probably sand-bagged in
fire-fighting.
Other related articles:
