Severity vs priority, and why they can diverge

• Severity – The degree of technical and business impact a defect has on the system: how badly it breaks functionality, data, or safety. Usually judged by the tester or by the nature of the bug.
• Priority – How urgently the defect must be fixed relative to other work. Judged by the product owner or business based on customer impact, revenue, reputation, and scheduling factors.
• Independence – They are independent axes: a defect can be any combination of high or low on each.
• Low-severity high-priority – A misspelled company name on the public homepage: cosmetic but brand-damaging, so fix it immediately.
• High-severity low-priority – A crash in a rarely used admin edge case with a manual workaround: serious but affects almost nobody, so schedule it later.

What is severity?

Severity is primarily a technical judgement about the defect itself. A crash, data corruption, a wrong monetary calculation, or a security hole are high severity because they damage core functionality, correctness, or safety. A cosmetic misalignment, a non-blocking warning, or a minor label issue is low severity because the system still works correctly.

Teams usually define severity levels with objective criteria so testers can classify consistently.

// Severity classification in a bug tracker model
package com.bank.qa;

public enum Severity {
    CRITICAL,   // System crash, data loss, security breach
    MAJOR,      // Core feature broken, no workaround
    MINOR,      // Feature works but with inconvenience
    TRIVIAL     // Cosmetic issue, typo, alignment
}

// Example: wrong interest calculation is CRITICAL
// because it moves wrong money amounts
public class InterestBug {
    public static void main(String[] args) {
        java.math.BigDecimal balance = new java.math.BigDecimal("100000.00");
        java.math.BigDecimal rate = new java.math.BigDecimal("7.0");
        // BUG: using double arithmetic instead of BigDecimal
        double wrongInterest = balance.doubleValue() * rate.doubleValue() / 100;
        System.out.println("Wrong interest: " + wrongInterest);
        // This rounding error on millions of accounts = CRITICAL severity
    }
}

What is priority?

Priority is a business and scheduling judgement about when to fix it. It weighs how many users are affected, whether there is a workaround, the revenue or compliance impact, reputational risk, the release schedule, and what else is competing for developer time.

Priority is usually set by the product owner or triage group, often in collaboration with the tester. The same defect can have its priority raised or lowered as business context changes.

package com.bank.qa;

public enum Priority {
    P1_IMMEDIATE,  // Fix now, deploy hotfix today
    P2_HIGH,       // Fix this sprint, within days
    P3_MEDIUM,     // Fix next sprint, within weeks
    P4_LOW         // Fix when convenient, backlog
}

// Example: logo typo on homepage
// Severity: TRIVIAL (nothing is broken)
// Priority: P1_IMMEDIATE (every customer sees it)
public class TriageBug {
    String title = "Bank name misspelled on homepage";
    Severity severity = Severity.TRIVIAL;
    Priority priority = Priority.P1_IMMEDIATE;
    String reason = "Every visitor sees the brand mistake";
}

Why do severity and priority diverge?

The two diverge because impact and urgency are different questions. A defect's technical damage does not determine how fast it must be fixed. Business context, user population, workarounds, and timing all factor into urgency independently.

| Combination | Example | Severity | Priority |
|---|---|---|---|
| High-high | Transfer debits wrong amount | CRITICAL | P1_IMMEDIATE |
| Low-high | Company name misspelled on homepage | TRIVIAL | P1_IMMEDIATE |
| High-low | Crash in rarely used admin report | CRITICAL | P4_LOW |
| Low-low | Alignment off on settings page | TRIVIAL | P4_LOW |

// High-severity, low-priority: crash in admin edge case
package com.bank.admin;

public class AdminReportGenerator {

    // This crashes on accounts with zero transactions
    // Severity: CRITICAL (crash)
    // Priority: P4_LOW (only one clerk uses it, workaround exists)
    public String generateReport(String accountId) {
        var transactions = transactionRepo.findByAccount(accountId);
        // BUG: NullPointerException when transactions is empty
        return transactions.get(0).toString(); // crashes
    }
}

How do you classify severity objectively?

Objective classification uses predefined criteria so testers do not argue about labels. A typical severity matrix for a banking application looks like this.

• Critical : System crash, data corruption, wrong monetary calculation, security breach, complete loss of a core feature with no workaround.
• Major : Core feature partially broken, significant data display error, major performance degradation, workaround exists but is painful.
• Minor : Feature works but with inconvenience, minor display issues, error in non-critical area.
• Trivial : Cosmetic issue, typo, alignment, color, tooltip wording.

// Severity classification helper
package com.bank.qa;

public class SeverityClassifier {

    public Severity classify(Defect defect) {
        if (defect.causesDataLoss() || defect.causesCrash()
            || defect.involvesWrongMoneyCalculation()) {
            return Severity.CRITICAL;
        }
        if (defect.coreFeatureBroken() && !defect.hasWorkaround()) {
            return Severity.MAJOR;
        }
        if (defect.coreFeatureBroken() && defect.hasWorkaround()) {
            return Severity.MINOR;
        }
        return Severity.TRIVIAL;
    }
}

How do you set priority correctly?

Priority uses severity as one input among many. The product owner also considers the number of affected users, whether a workaround exists, revenue and compliance impact, reputational risk, and what else is in the sprint.

A good bug report captures the facts the product owner needs: affected-user count, workaround availability, business impact, and compliance implications.

// Bug report with the facts needed for priority
package com.bank.qa;

import java.time.LocalDateTime;

public class BugReport {
    String id = "BUG-4521";
    String title = "Interest calculation rounds down instead of half-up";
    Severity severity = Severity.CRITICAL;
    Priority priority = null; // Set by product owner in triage

    // Facts for triage
    int affectedUsers = 250000;      // All savings account holders
    boolean workaroundExists = false;
    String businessImpact = "Underpays interest by up to 0.01 per account per day";
    String complianceRisk = "RBI regulation requires correct interest calculation";
    LocalDateTime foundDate = LocalDateTime.now();
    String environment = "production";

    // Triage decision: P1_IMMEDIATE because of user count and compliance
}

What are common mistakes?

The first mistake is conflating severity and priority into a single field. When a tracker has only "High / Medium / Low" without specifying which axis, the team argues endlessly because the tester means severity and the product owner means priority.

Wrong: Single field "Importance: High"
       Tester thinks: it crashes (severity)
       PM thinks: nobody uses that screen (priority)
       Result: argument, no resolution

Correct: Two fields
       Severity: CRITICAL (it crashes)
       Priority: P4_LOW   (nobody uses it, workaround exists)
       Result: clear, no argument

The second mistake is letting severity automatically determine priority. A critical bug is not always the most urgent fix. If only one internal user triggers it and a workaround exists, other work may be more urgent.

The third mistake is not capturing the workaround and affected population in the bug report. Without those facts, the product owner cannot set priority correctly.

What should a senior engineer know?

• Severity informs priority but does not determine it. The business decides priority using severity as one input among many. A senior tester provides the facts; the product owner makes the call.
• Priority can change; severity rarely does. A bug becomes high priority the week before a major launch, even if it was low priority last month. Severity is intrinsic to the defect.
• Compliance and regulation override normal priority. In banking, a defect that violates RBI regulations is immediately P1 regardless of how many users are affected, because the regulatory risk is existential.
• Triage meetings resolve priority disputes. When the tester and the developer disagree, the triage group, product owner, tech lead, and QA lead, decides priority collectively with all the facts on the table.

// Regulatory override in priority setting
package com.bank.qa;

public class PrioritySetter {

    public Priority determinePriority(BugReport bug) {
        // Compliance always overrides
        if (bug.complianceRisk != null && !bug.complianceRisk.isEmpty()) {
            return Priority.P1_IMMEDIATE;
        }
        // High severity + many users = immediate
        if (bug.severity == Severity.CRITICAL && bug.affectedUsers > 1000) {
            return Priority.P1_IMMEDIATE;
        }
        // High severity + few users + workaround = later
        if (bug.severity == Severity.CRITICAL && bug.workaroundExists) {
            return Priority.P3_MEDIUM;
        }
        // Low severity + visible to all = high priority
        if (bug.severity == Severity.TRIVIAL && bug.affectedUsers > 100000) {
            return Priority.P2_HIGH;
        }
        return Priority.P3_MEDIUM;
    }
}

What are common interview follow-up questions?

• "Give me a real example of low-severity high-priority." A misspelled bank name on the public homepage: cosmetically trivial but every visitor sees the brand mistake.
• "Give me a real example of high-severity low-priority." A NullPointerException in a quarterly admin report that one clerk runs, with a manual workaround of exporting from the database directly.
• "Who sets severity and who sets priority?" The tester sets severity based on the nature of the defect. The product owner sets priority based on business context.
• "What happens when the tester and developer disagree on severity?" The objective criteria in the severity matrix resolve it. If the defect causes a crash, it is critical regardless of opinion.