Bug severity

Bug severity describes how badly a defect affects the product: what breaks, for whom, and whether there is a workaround. It is a technical judgement about impact, and testers usually assign it when they report the bug. Severity says nothing directly about when the bug will be fixed; that is priority.

Typical scale

Names vary between teams and trackers, but most use four or five levels:

Severity	Meaning	Example
Critical / Blocker	System down, data loss or corruption, security breach, no workaround	Checkout throws a 500 for every user
Major / High	A main feature is broken or wrong, workaround is painful or absent	Refunds are calculated with the wrong tax rate
Moderate / Medium	Feature partly broken, reasonable workaround exists	CSV export ignores the date filter; you can filter in a spreadsheet
Minor / Low	Small functional issue with little impact	Sort order of a rarely used list is reversed
Trivial / Cosmetic	Visual or text issue, no functional effect	Misaligned icon, typo in a tooltip

Severity vs priority

Severity = impact of the defect (technical, set by QA). Priority = urgency of the fix (business, set by the product owner or triage).

They are independent, which is why interviewers ask for examples of each combination:

• High severity, low priority: the app crashes when importing a file format that a single legacy customer uses once a year.
• Low severity, high priority: the company name is misspelled on the home page the day before a launch.
• High severity, high priority: payment fails for all users.
• Low severity, low priority: a typo on a rarely visited settings page.

Common mistakes

• Inflating severity to get a bug fixed faster. That is what priority is for. Inflated severity makes the metric meaningless.
• Rating by how annoying it was to find. Rate by user and business impact, and say who is affected and how often.
• Ignoring the workaround. The same failure is more severe when there is no way around it.