Priority by the English definition is used in the comparison of two things or conditions, where one has to be given more importance than the other(s) and has to be tackled with/resolved first before proceeding to the next one(s). Therefore in the context of defects, the priority of a defect would indicate the urgency with which it would need to be fixed.
Priority is defined as the order in which a defect should be fixed. Higher the priority the sooner the defect should be resolved.
Defects that leave the software system unusable are given higher priority over defects that cause a small functionality of the software to fail.
QA classifies the defect under appropriate severity based on the complexity and criticality of the defects. Any business stakeholders including the project managers, business analysts, product owner define the priority of the defects.
Classification
Broadly, Priority of the defects can be classified as follows:
Priority #1) Immediate/Critical (P1) – This has to be fixed immediately within 24 hours. This generally occurs in cases when an entire functionality is blocked and no testing can proceed as a result of this. Or in certain other cases if there are significant memory leaks, then generally the defect is classified as a priority -1 meaning the program/ feature is unusable in the current state.
Any defect that needs immediate attention which impacts the testing process will be classified under the immediate category. All the Critical severity defects fall under this category (unless re-prioritized by business/stakeholders)
Priority #2) High (P2) – Once the critical defects have been fixed, a defect having this priority is the next candidate which has to be fixed for any test activity to match the “exit” criteria. Normally when a feature is not usable as it’s supposed to be, due to a program defect, or that a new code has to be written or sometimes even because some environmental problem has to be handled through the code, a defect may qualify for a priority 2.
This is the defect or issue which should be resolved before the release is made. These defects should be resolved once the Critical issues are solved. All the Major severity defects fall into this category.
Priority #3) Medium (P3) – A defect with this priority must be in contention to be fixed as it could also deal with functionality issues which are not as per expectation. Sometimes even cosmetic errors such as expecting the right error message during the failure could qualify to be a priority 3 defect.
This defect should be resolved after all the serious bugs are fixed. Once the Critical and the High priority bugs are done, we can go for the medium priority bugs. All the Minor severity defects fall into this category.
Priority #4) Low (P4) – A defect with low priority indicates that there is definitely an issue, but it doesn’t have to be fixed to match the “exit” criteria. However, this must be fixed before the GA is done. Typically, some typing errors or even cosmetic errors as discussed previously could be categorized in here. Sometimes defects with priority low are also opened to suggest some enhancements in the existing design or a request to implement a small feature to enhance user experience.
This defect can be resolved in future and does not need any immediate attention and the Low severity defects fall into this category.
As already discussed priority determines how quickly the defect turnaround time must be. If there are multiple defects, the priority decides which defect has to be fixed and verified immediately versus which defect can be fixed a bit later.
