Glossary · Testing fundamentals
Bug priority
Also called: defect priority, priority level, priority levels
Definition
How urgently a defect should be fixed relative to other work, decided by business need. Usually set by the product owner or during bug triage.
Bug priority describes the order in which defects get fixed. It is a business decision that weighs user impact, deadlines, customer commitments, reputation and the cost of the fix. Testers may suggest a priority, but the final call usually belongs to the product owner, often in a triage meeting with development and QA.
Typical scale
| Priority | Meaning |
|---|---|
| P1 / Urgent | Fix immediately, may need a hotfix outside the normal release |
| P2 / High | Fix in the current sprint or before the next release |
| P3 / Medium | Schedule in a future sprint |
| P4 / Low | Fix when convenient, or accept and close |
Priority vs severity
Severity measures impact: how badly the product is broken. Priority measures urgency: how soon it must be fixed. They are rated separately because they often disagree.
- Low severity, high priority: a wrong price displayed in a banner for a campaign launching tomorrow. Nothing crashes, but it has to be right before launch.
- High severity, low priority: a crash in an admin report that only runs at year end, eleven months away.
Priority also changes over time while severity usually does not. That same year-end crash becomes P1 in December.
How priority is decided
Useful questions during triage:
- How many users are affected, and which ones (paying customers, internal staff, one tenant)?
- Is there a workaround, and can support explain it?
- Is there a release, demo, legal or contractual deadline?
- What is the cost and risk of the fix itself? A risky fix late in a release may be deferred deliberately.
Common mistakes
- Using one field for both. Teams that track only “priority” lose the information about impact, which matters for release risk and metrics.
- Everything is P1. When most bugs are urgent, none are. Keep the top level rare and well defined.
- Never revisiting priority. Reassess open bugs when the release plan or customer situation changes.