Schweregrad vs. Priorität: welcher Bug zuerst behoben wird

Jeder Bug-Report beantwortet zwei Fragen, ob er es ausspricht oder nicht: wie schlimm ist es und wie schnell beheben wir es. Die erste Frage ist der Schweregrad (Severity), die zweite die Priorität (Priority). Beides klingt nach demselben und landet in vielen Projekten in einem einzigen Label wie „dringend“. So kommt es, dass ein Tippfehler ein Release blockiert, während ein kaputtes Formular bis nächste Woche wartet.

In diesem Beitrag geht es um den Unterschied, warum die beiden oft in entgegengesetzte Richtungen zeigen und wie ich beide nutze, um zu entscheiden, was zuerst behoben wird.

Schweregrad: wie viel Schaden der Bug anrichtet#

Der Schweregrad beschreibt den Bug selbst: was kaputt ist, für wen und ob es einen Umweg gibt. Er hängt nicht vom Kalender ab. Ein Checkout, der fehlschlägt, ist an einem Dienstag genauso schwer wie am Tag des Launches. Ich verwende vier Stufen:

1. Kritisch: Die Website oder ein zentraler Ablauf funktioniert nicht, und es gibt keinen Umweg. Das Kontaktformular scheitert stillschweigend, der Checkout wirft einen Fehler, Seiten liefern einen 500er.
2. Schwer: Eine wichtige Funktion ist kaputt oder falsch, aber es gibt einen Umweg. Das mobile Menü öffnet sich in Safari nicht, die Links im Footer funktionieren aber noch.
3. Gering: Etwas stimmt nicht, hält aber niemanden auf. Ein Filter vergisst seinen Zustand nach dem Zurückgehen, ein Bild ist bei einer Bildschirmgröße unglücklich beschnitten.
4. Kosmetisch: Ein Abstand, der 4 Pixel daneben liegt, eine Hover-Farbe, die nicht zum Design passt.

Den Schweregrad legt meist fest, wer den Bug findet und nachstellt: ein Tester, ein Entwickler oder ich bei der QA. Es ist eine technische Einschätzung und sollte deshalb gleich ausfallen, egal wer sie aufschreibt.

Priorität: wie schnell er behoben wird#

Die Priorität beschreibt das Projekt, nicht den Bug. Sie beantwortet, wann die Korrektur passieren soll, gemessen an allem anderen, was gerade läuft: dem Launch-Termin, wie viele Besucher betroffen sind, wovon eine Kampagne abhängt, was der Kunde wem zugesagt hat. Derselbe Bug kann über Nacht seine Priorität ändern, ohne sich selbst zu ändern.

• P1: sofort beheben, alles andere wartet.
• P2: vor dem nächsten Release oder Launch beheben.
• P3: einplanen und beheben, wenn im Zeitplan Platz ist.
• P4: wäre schön. Beheben, wenn ohnehin an dieser Stelle gearbeitet wird, oder schließen.

Die Priorität ist eine geschäftliche Entscheidung und gehört deshalb dem Kunden oder der Projektverantwortlichen. Meine Aufgabe ist, ihnen zu geben, was sie dafür brauchen: den Schweregrad, wer betroffen ist und was die Korrektur kostet.

Wenn Schweregrad und Priorität nicht übereinstimmen#

Wären Schweregrad und Priorität immer gleich, bräuchte man nicht zwei Felder. Spannend sind die Fälle, in denen sie auseinandergehen.

Hoher Schweregrad, niedrige Priorität#

Das News-Archiv von 2019 liefert auf Seite 14 einen 500er. Technisch ist das kritisch: Die Seite funktioniert nicht, und es gibt keinen Umweg. Aber seit Monaten hat sie niemand besucht, sie ist nirgends verlinkt, und das Archiv fällt beim Redesign im nächsten Quartal ohnehin weg. Das wird ein P3 oder wird geschlossen, wenn das Archiv verschwindet.

Niedriger Schweregrad, hohe Priorität#

Der Firmenname des Kunden ist in der Hero-Überschrift falsch geschrieben. Nichts ist kaputt, die Korrektur ist ein einziges Wort, der Schweregrad also kosmetisch. Aber morgen früh startet die Kampagne, die Besucher auf genau diese Seite schickt, und die Überschrift ist das Erste, was jeder liest. Das ist ein P1.

Wenn beide übereinstimmen#

Das Kontaktformular sieht aus, als würde es senden, aber die E-Mail kommt nie an. Kritisch, weil der Hauptzweck der Website kaputt ist, ohne dass es jemand merkt, und P1, weil jede Stunde im Live-Betrieb Anfragen kostet. Am anderen Ende: ein Footer-Icon, das bei einer Tablet-Breite 2 Pixel tiefer sitzt als seine Nachbarn, ist kosmetisch und P4.

Der Schweregrad ist eine Tatsache über den Bug. Die Priorität ist eine Entscheidung über das Projekt.

Wie ich es aufschreibe#

Jeder Bug, den ich melde, bekommt beide Felder und genug Details, damit jemand anderes ihn ohne Rückfrage nachstellen kann. Ein kurzes, einheitliches Format spart mehr Zeit als jedes Tool:

## Kontaktformular verschickt keine E-Mails

**Schweregrad:** Kritisch (zentraler Ablauf kaputt, kein Umweg)
**Priorität:** P1 (Kampagnen-Traffic startet morgen)

**Schritte zum Nachstellen**
1. /de/contact/ in einem beliebigen Browser öffnen
2. Alle Felder ausfüllen und absenden

**Erwartet:** Bestätigung erscheint, E-Mail kommt bei hello@example.com an
**Tatsächlich:** Bestätigung erscheint, keine E-Mail kommt an (SMTP-Authentifizierungsfehler im Log)

**Umgebung:** Produktion, alle Browser

Die Begründung in Klammern ist wichtig. „P1“ allein lädt zur Diskussion ein. „P1, weil die Kampagne morgen startet“ beendet sie und macht sichtbar, wann der Grund nicht mehr gilt.

Die Liste abarbeiten#

Wenn die Liste lang ist, folgt die Reihenfolge der Arbeit zuerst der Priorität. Der Schweregrad entscheidet zwischen Bugs mit gleicher Priorität. Im Code ist das eine Sortierung mit zwei Schlüsseln:

type Severity = "critical" | "major" | "minor" | "trivial";
type Priority = "P1" | "P2" | "P3" | "P4";

interface Bug {
  title: string;
  severity: Severity;
  priority: Priority;
}

const PRIORITY: Record<Priority, number> = { P1: 0, P2: 1, P3: 2, P4: 3 };
const SEVERITY: Record<Severity, number> = { critical: 0, major: 1, minor: 2, trivial: 3 };

// Priority decides the order. Severity only breaks ties.
export function triage(bugs: Bug[]): Bug[] {
  return [...bugs].sort(
    (a, b) =>
      PRIORITY[a.priority] - PRIORITY[b.priority] ||
      SEVERITY[a.severity] - SEVERITY[b.severity],
  );
}

Daran sieht man auch den häufigsten Fehler: nur nach Schweregrad zu sortieren. So verbringt ein Team den Launch-Tag damit, die kritische, aber bedeutungslose Archivseite zu reparieren, während die falsch geschriebene Überschrift vor allen Augen live geht.

Der Schweregrad spielt auch eine Rolle dabei, wann Bugs gefunden werden: Ein kritischer Bug, der in der Entwicklung auffällt, ist schnell behoben, derselbe Bug beim Besucher wird teuer. Darüber habe ich in Warum Bugs entstehen und warum es sich lohnt, sie früh zu finden geschrieben. Wie ich vor einem Launch teste, steht in Was QA für eine Website bedeutet.

Das Fazit#

Führen Sie Schweregrad und Priorität als zwei getrennte Felder. Den Schweregrad legt fest, wer den Bug nachstellt, und er beschreibt den Schaden. Die Priorität legt fest, wem das Projekt gehört, und sie beschreibt den Zeitpunkt. Wenn beide auseinandergehen, entscheidet die Priorität über die Reihenfolge, und der Grund dafür gehört aufgeschrieben.

Wenn Ihre Bug-Liste zu einer Wand aus „dringenden“ Tickets geworden ist oder Sie möchten, dass jemand Ihre Website vor dem Launch testet und die Funde sortiert, schreiben Sie mir. Ich sage Ihnen, was zuerst behoben werden sollte und warum.