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.
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.
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.
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):
- Fix version
- FAD (functions as designed)
Other related articles: