Severity vs Priority
When a bug moves from "New" to "Assigned" in the bug life cycle, someone has to decide two things about it that get confused constantly, including in interviews: how bad is this bug and how soon does it need fixing. Those sound like the same question. They aren't. One is a technical judgment; the other is a business judgment; and they can point in completely different directions on the same bug.
Severity: How Bad Is the Impact?
Severity measures the technical impact of a bug on the application — how badly it breaks functionality, regardless of who is affected or when. It's usually set by the tester who found the bug, based purely on what the software does wrong: does it crash, corrupt data, block a core flow, or is it a minor cosmetic issue? Severity doesn't care whether the CEO is watching a demo tomorrow — that's not a technical question.
Priority: How Urgently Must It Be Fixed?
Priority measures business urgency — how soon this bug needs to be fixed relative to everything else in the backlog. It's usually set by the test lead or product owner during triage, and it factors in things severity alone can't see: how many users hit this path, whether there's a release or demo deadline, whether a workaround exists, and how visible the bug is to important stakeholders.
Why They're Independent
Because severity is about the code and priority is about the business, a bug can land on any combination of the two. A crash is always technically severe, whether or not anyone urgently cares about the screen where it happens. A typo is always technically trivial, whether or not fixing it today matters enormously to someone important. This is the single most common thing testers get tested on in interviews, so it's worth memorizing through examples rather than definitions.
The Four Combinations, with RecipeBox Examples
| Severity / Priority | RecipeBox Bug Example | Why |
|---|---|---|
| High Severity, High Priority | Tapping "Save" on the Add Recipe screen crashes the app for every user, on every device. | Technically catastrophic (core feature completely unusable) and urgent — it must be fixed before the next release ships, or the app is unusable. |
| High Severity, Low Priority | The rarely-used "Export all recipes as backup file" admin/debug screen (used by almost no real users) crashes the app when tapped. | Technically severe (a crash is a crash) but low priority, because almost nobody uses that screen — it can wait for a future release without meaningfully hurting users. |
| Low Severity, High Priority | The RecipeBox logo is misspelled as "RecipBox" on the Login screen, and there's an investor demo tomorrow morning. | Technically trivial (pure cosmetic typo, nothing is broken) but urgent right now because of who will see it and when — it needs fixing before tomorrow regardless of how "small" it is. |
| Low Severity, Low Priority | On the Recipe List screen, the category label uses slightly inconsistent capitalization ("Breakfast" vs "dessert"). | Minor cosmetic inconsistency with no functional impact and no deadline pressure — it goes into the backlog to be cleaned up whenever there's spare time. |
Who Decides What
| Field | Typically set by | Based on |
|---|---|---|
| Severity | The tester who found the bug | Technical impact: crash, data loss, blocked flow, cosmetic, etc. |
| Priority | Test lead / product owner during triage (sometimes adjusted after discussion with the tester) | Business context: user impact, deadlines, visibility, workarounds |