Severity vs priority, and regression testing

Two things confuse newcomers to QA and matter daily: the difference between a bug's severity and its priority (they are not the same, and conflating them causes bad decisions), and regression testing — making sure a change did not break something that used to work. This lesson covers both, closing the manual craft module.

Severity versus priority

Every bug has two independent attributes, and keeping them separate is a mark of a competent QA:

Severity — how bad is the bug's impact when it occurs? A crash, data loss, or money moving wrong is high severity; a misaligned label is low severity. Severity is about the technical/impact seriousness and is largely the QA's call (you saw what it does).
Priority — how urgently should it be fixed, relative to everything else? This is a business call (product owner/team), weighing severity against frequency, who is affected, business cost, and what else is competing for the developer's time.

They are independent — a bug can be any combination:

	High priority	Low priority
High severity	A crash on the main top-up flow — fix now	A crash in a rarely-used admin screen no customer touches
Low severity	A typo in the company name on the login screen — trivial impact but embarrassing and everyone sees it	A cosmetic misalignment on a settings page

The instructive cells are the off-diagonal ones: a high-severity, low-priority bug (a nasty crash, but in a feature nobody uses, or behind a flag) can wait; a low-severity, high-priority bug (a one-character typo, trivial impact, but it is the company name on every screen and looks terrible) should be fixed immediately. So "severe" does not mean "urgent", and "urgent" does not mean "severe". A QA assigns severity (the impact you observed) and proposes a priority, but the team owns the priority decision. Confusing the two — treating every high-severity bug as a drop-everything emergency, or dismissing a low-severity one that is highly visible — leads to fixing the wrong things first.

Severity levels, and money

A common severity scale, with the money lens this course emphasises:

Critical — the app is unusable or data/money is lost: a crash on launch, a top-up that charges twice, a balance that reconciles wrong. On a money app, any transaction correctness bug is at least high, usually critical — money moving wrong is the worst kind of bug.
High — a major feature is broken but there is a workaround, or a serious but non-money defect.
Medium — a feature works but with a noticeable problem; a limited-impact defect.
Low — cosmetic or minor; does not affect function.

For the mobile-money apps here, calibrate severity around money and data integrity: a double-charge, a lost transaction, one user seeing another's balance — these are critical regardless of how "small" they look in the UI, because the impact is real money and trust. A QA on such a product treats transaction-correctness bugs as the most severe class, and says so clearly in the report.

Regression testing: did the change break something else?

The other half of the lesson. When a developer fixes a bug or adds a feature, two things can go wrong: the fix might not work (you re-test that — sanity testing), and — the subtler risk — the change might break something that used to work. Regression testing is re-running tests on the existing, previously-working functionality to confirm the change did not break it.

Why it matters: software is interconnected. A change to the top-up code might inadvertently break the withdrawal flow that shares some logic; a fix to one screen might break another. The bug the developer fixed is not the only risk — the fix itself is a risk to everything around it. Regression testing guards against this, and it is a large, ongoing part of a QA's work: every release, you re-verify that the important existing features still work, not just the new change.

What to re-run: you cannot re-test everything

The challenge is that you cannot re-run every test on every change — that would be endless. So regression testing is about choosing what to re-run, by risk and by relatedness:

Around the change — features that share code or data with what changed are most likely to be affected; re-test those first.
The critical paths — regardless of the change, always re-verify the most important flows (login, top-up, the money paths) — a regression there is the most costly.
Previously buggy areas — features that have broken before tend to break again; keep an eye on them.
A core regression suite — a curated set of tests covering the essential functionality, re-run every release. Keeping this focused (not "everything") is the skill.

And this is exactly where automation earns its place (the automation modules): regression testing is repetitive, done every release, and boring to do by hand — the perfect candidate to automate, freeing the QA to explore the new change manually while the automated suite re-checks the old. A well-chosen automated regression suite that runs on every change is one of the highest-value things a QA team builds — provided it is trustworthy (the flaky-tests lesson), because a regression suite nobody trusts is worse than none.

Check your work

Severity vs priority. Severity = how bad the impact (largely QA's call, from what you observed); priority = how urgent to fix relative to everything else (a business call). Independent — high-severity can be low-priority (crash in an unused screen) and low-severity can be high-priority (a typo in the company name everywhere). Do not conflate them.

Severity levels + money. Critical (unusable / money or data lost — includes any transaction-correctness bug), high, medium, low. On money apps, calibrate around money/data integrity: double-charge, lost transaction, cross-user data are critical however small they look.

Regression testing. Re-running tests on existing, previously-working functionality to confirm a change did not break it (distinct from sanity — re-testing the fix itself). Software is interconnected; the fix is a risk to everything around it. A large, ongoing part of QA.

What to re-run. You cannot re-test everything — choose by risk/relatedness: around the change, the critical/money paths always, previously-buggy areas, and a curated core regression suite. Regression is the prime candidate for automation (repetitive, every release) — if the suite is trustworthy.

Practice

For five bugs (invent or recall), assign a severity and a priority independently, and find one that is high-severity/low-priority and one that is low-severity/high-priority.
Justify why a UI double-charge bug is critical even though the visible glitch is "small".
Given a change to the top-up code, list which existing features you would regression-test first, and why (relatedness + criticality).
Curate a 10-item core regression suite for a mobile-money app — the flows you re-run every release.
Argue why regression testing is the best candidate for automation, and what would make an automated regression suite worthless (a preview of the flaky-tests lesson).
Draft how you would state a bug's severity to the team and propose (not dictate) its priority.

Official documentation

ISTQB — Foundation syllabus (severity, priority, regression) — Standard definitions and the distinction.
ISTQB — Glossary — Precise definitions of severity, priority, regression, sanity.
Ministry of Testing — Regression and risk — Practitioner approaches to choosing what to regression-test.

Next: HTTP for testers — requests, responses and status codes.