Severity HighPriority High
- Checkout fails with a 500 error for all card payments
- Users can see other customers' order history
- App crashes on launch on the most-used Android version
QA-Dokumentation
Schweregrad und Priorität von Bugs
Definitionen, echte Beispiele und eine Entscheidungshilfe mit 4 Fragen.
Läuft vollständig in Ihrem Browser Ohne Anmeldung
Decision helper
Suggestion
- Severity
- Major
- Priority
- P2 High
Why
- A partially broken feature starts at Major.
- Customer-visible problems are scheduled for the current release.
These rules give a consistent starting point. Your team’s definitions and the triage owner have the final say; priority in particular depends on business context this helper cannot see.
Severity vs priority: the 2 × 2
Severity is the technical impact on the system. Priority is how soon the business needs it fixed. They are set independently, often by different people (QA proposes severity; the product owner decides priority).
Severity HighPriority Low
- Report export crashes the app, but only on a legacy browser used by 0.1% of users
- Data corruption in a feature behind a disabled feature flag
- Crash when importing a 2 GB file when the documented limit is 50 MB
Severity LowPriority High
- Company name misspelled in the homepage header
- Wrong price shown in a launch-day marketing banner (checkout charges correctly)
- Partner logo missing on a page required by a contract
Severity LowPriority Low
- Tooltip text misaligned by a few pixels in an admin settings page
- Inconsistent capitalisation in a rarely used dialog
- Footer link hover colour differs from the design
Severity levels
| Level | Definition and example |
|---|---|
| Blocker | Stops testing or use of the product entirely: crash on start, cannot sign in, build not deployable. No workaround.e.g. App crashes on launch; sign-in returns HTTP 500 for every user. |
| Critical | A core function fails, data is lost or corrupted, or there is a security/privacy breach. No acceptable workaround.e.g. Customers are charged twice; one user can read another user’s invoices. |
| Major | A significant function does not work as specified, but there is a workaround or the impact is limited to part of the feature.e.g. Search ignores the date filter; export fails over 10 MB but smaller exports work. |
| Minor | Behaviour is wrong but the function is usable: unclear error message, wrong default, layout problem that does not hide content.e.g. Error says “Invalid input” without naming the field; wrong default sort order. |
| Trivial | Cosmetic issue with no functional impact: spacing, alignment, minor wording in rarely seen places.e.g. A settings dialog button is 2px out of alignment. |
Priority levels
| Level | Meaning |
|---|---|
| P1 Highest | Fix now. Hotfix or blocks the release; someone starts on it today. |
| P2 High | Fix in the current sprint/release before shipping. |
| P3 Medium | Fix in a planned upcoming release. |
| P4 Low | Fix when convenient; may be batched or deferred to the backlog. |
Jira’s default priorities (Highest, High, Medium, Low, Lowest) map naturally onto P1–P4 with Lowest as a backlog bucket. Names vary between teams; agree on definitions, not just labels.
Common mistakes
- Setting priority equal to severity by default. Severity describes impact on the system; priority is a business scheduling decision. They are often different.
- Inflating severity to get a bug fixed sooner. It erodes trust in triage; argue for priority instead, with the business reason.
- Rating a crash as Critical without checking reach. A crash in an unreachable code path is still high severity, but rarely high priority.
- Treating all cosmetic issues as Trivial. A broken layout that hides the Buy button is a functional problem.
- Never revisiting priority. A Low-priority bug can become urgent when a customer escalates or a launch date approaches.
- Leaving security and data-loss bugs at default severity. These are at least Critical until someone with context downgrades them.
Über dieses Tool
Streit in der Bug-Triage entsteht meist, weil zwei Fragen vermischt werden. Der Schweregrad (Severity) beschreibt, wie stark der Bug das Produkt beeinträchtigt; die Priorität, wie bald das Business die Behebung braucht. Ein Tippfehler im Firmennamen auf der Startseite hat niedrigen Schweregrad, aber hohe Priorität, während ein Absturz in einem Report, der nur über einen nicht unterstützten Browser erreichbar ist, hohen Schweregrad und niedrige Priorität haben kann. Diese Seite definiert fünf Schweregrad- und vier Prioritätsstufen mit je einem Beispiel, zeigt die klassische 2×2-Matrix mit Praxisfällen und die Fehler, die am meisten Reibung verursachen. Die Entscheidungshilfe stellt vier Fragen zu Auswirkung, Workaround, Reichweite und geschäftlicher Sichtbarkeit, schlägt dann Schweregrad und Priorität vor und erklärt jeden Schritt der Begründung. So können Sie ein Team kalibrieren, statt das Urteilsvermögen zu ersetzen.
So funktioniert es
- Beantworten Sie die vier Fragen zum Bug: Auswirkung, Workaround, Anzahl betroffener Nutzer und geschäftliche Sichtbarkeit.
- Lesen Sie den vorgeschlagenen Schweregrad, die Priorität und die Begründung.
- Vergleichen Sie mit den 2×2-Beispielen und den Stufendefinitionen und kopieren Sie den Vorschlag in Ihr Ticket.
FAQ zu Schweregrad und Priorität von Bugs
Wer legt den Schweregrad fest und wer die Priorität?
Üblicherweise schlägt der Tester den Schweregrad vor, weil er die technische Auswirkung beschreibt, und der Product Owner oder Triage-Verantwortliche legt die Priorität fest, weil sie von geschäftlichem Kontext, Release-Terminen und Kundenzusagen abhängt.
Kann sich der Schweregrad nach der Meldung ändern?
Ja. Zeigt die Analyse Datenverlust, eine Sicherheitsauswirkung oder eine viel größere Reichweite als zunächst gedacht, erhöhen Sie ihn. Wird ein Workaround gefunden, kann er sinken. Halten Sie den Grund in einem Kommentar fest.
Passen diese Stufen zu Jira?
Das Standard-Prioritätsfeld von Jira verwendet Highest, High, Medium, Low und Lowest; der Schweregrad ist meist ein benutzerdefiniertes Feld. Die Bezeichnungen hier sind gängige Konventionen. Entscheidend ist, dass Ihr Team seine Definitionen aufschreibt und einheitlich anwendet.