Severity vs Priority
Severity describes the technical impact of a defect on the system, while priority indicates the urgency with which it should be fixed based on business needs.
Severity is objective and technical: how badly does the defect affect the system? Common severity levels are Critical (system crash, data loss), Major (key feature broken, no workaround), Minor (feature works but with an inconvenient workaround), and Trivial (cosmetic issue).
Priority is subjective and business-driven: how soon should this be fixed? A typo on the homepage (low severity) might be high priority because it damages brand credibility. A crash in an admin tool used by one person (high severity) might be lower priority than a minor visual glitch on the landing page seen by millions.
Why It Matters for QA Teams
Confusing severity with priority leads to misallocated effort. QA teams must communicate both dimensions clearly so that developers fix the right bugs in the right order.
Example
A defect causes the site's favicon to not display (Severity: Trivial). However, the CEO notices it before an investor demo and marks it as Priority: Urgent. Meanwhile, a crash affecting the rarely used bulk CSV import tool (Severity: Critical) is set to Priority: Medium because only one internal user is impacted and they have a manual workaround.