Ein falsch geschriebener Firmenname auf der Startseite und ein Absturz in einer selten genutzten Exportfunktion: Was beheben Sie zuerst? Argumente wie diese sind der Grund, warum Testteams zwischen Schweregrad und Priorität unterscheiden. Einer beschreibt den technischen Schaden, der andere beschreibt die geschäftliche Dringlichkeit.

Ohne diese Unterscheidung wird jeder Fehler als „kritisch“ eingestuft, die Bezeichnungen verlieren ihre Bedeutung und die Entwickler vertrauen ihnen nicht mehr. Dieser Leitfaden bietet Ihnen klare Definitionen und Beispiele sowie einen einfachen Prozess zum Treffen dieser Entscheidungen. Die Beispiele dienen der Veranschaulichung und die genauen Maßstäbe unterscheiden sich je nach Team und Tool.

Die kurze Antwort

Schweregrad Antworten: Wie stark wirkt sich dieser Fehler auf das Produkt aus? Ein Absturz oder Datenverlust ist schwerwiegend, ein kosmetischer Fehler jedoch nicht.

Prioritäre Antworten: Wie schnell sollten wir das Problem beheben? Das hängt von den betroffenen Kunden, den Fristen, dem Umsatz, der rechtlichen Gefährdung und dem Ruf der Marke ab.

Denken Sie an ein Krankenhaus. Der Schweregrad gibt an, wie ernst der Zustand des Patienten ist. Priorität hat die Reihenfolge, in der Patienten behandelt werden. Diese hängt auch von anderen Faktoren ab, beispielsweise davon, wer sicher warten kann und welche Ressourcen frei sind.

Schweregrad vs. Priorität nebeneinander

Schweregrade

Die meisten Teams verwenden etwa vier oder fünf Ebenen. Hier ist eine gängige Skala:

Prioritätsstufen

Schreiben Sie auf, was jede Stufe für Ihr Team bedeutet, idealerweise mit einer Zielreaktionszeit für jede Stufe. „P1 bedeutet, dass jemand innerhalb einer Stunde anfängt“ ist weitaus nützlicher als „P1 bedeutet sehr wichtig“.

Die vier Kombinationen mit Beispielen

Der beste Weg, dies zu verstehen, besteht darin, sich jede Kombination anzusehen:

Hoher Schweregrad, hohe Priorität

Der Checkout schlägt für alle fehl, das Unternehmen verliert von Minute zu Minute Geld und es gibt keine Lösung. Das ist der offensichtliche Fall: Alles fallen lassen und reparieren.

Hoher Schweregrad, niedrige Priorität

Die Anwendung stürzt beim Exportieren in ein älteres Format ab. Technisch gesehen ist das ein schwerwiegender Fehler. Aber wenn nur ein kleiner Teil der Benutzer jemals diese Funktion nutzt und ein modernes Format einwandfrei funktioniert, kann es auf eine geplante Veröffentlichung warten.

Niedriger Schweregrad, hohe Priorität

Der Firmenname ist auf der Homepage falsch geschrieben. Nichts ist kaputt und keine Daten sind gefährdet. Doch jeder Besucher sieht es, es schadet dem Vertrauen, und wenn morgen eine große Markteinführung ansteht, muss es heute behoben werden.

Niedriger Schweregrad, niedrige Priorität

Ein kleiner Tippfehler in einem selten besuchten Hilfeartikel. Reparieren Sie es, wenn es Ihnen passt. Wenn Ihr Rückstand damit voll ist, sollten Sie erwägen, sie in einer einzigen Bereinigungsaufgabe zusammenzufassen.

Ein Fehler, zwei unterschiedliche Prioritäten

Derselbe Fehler kann je nach Kontext unterschiedliche Prioritäten verdienen. Angenommen, eine Bestellbestätigungs-E-Mail wird mit dem falschen Logo versendet.

Der Schweregrad hat sich nicht geändert, da die Auswirkungen auf das System dieselben sind. Aber die Geschäftslage tat es. Auch die Zeit kann Dinge verändern. Ein Fehler, der heute P3 ist, kann in der Woche vor dem Go-Live eines Großkunden zu P1 werden.

Wer entscheidet über Schwere und Priorität?

• Tester schlagen normalerweise einen Schweregrad vor, da sie das Verhalten gesehen haben und die Auswirkungen auf das System verstehen.
• Produktbesitzer oder -manager entscheiden normalerweise über die Priorität, da sie Kunden, Umsatz und die Roadmap abwägen.
• Entwickler fügen Informationen über die Ursache, das Risiko einer Behebung und die Dauer hinzu.
• Supportteams liefern Beweise dafür, wie viele Kunden betroffen sind und wie stark.

Quellen und Teams variieren hinsichtlich dieser Verantwortlichkeiten, und in einem kleinen Startup kann eine Person alles erledigen. Wichtig ist, dass jeder weiß, wer die letzte Entscheidung trifft, sodass Meinungsverschiedenheiten mit einer Entscheidung enden.

So beurteilen Sie einen Fehler

Wenn Sie unsicher sind, gehen Sie diese Fragen durch.

Zum Schweregrad:

1. Verliert oder beschädigt es Daten oder legt es private Informationen offen?
2. Verhindert es, dass eine Hauptfunktion funktioniert?
3. Gibt es eine Problemumgehung und könnte ein normaler Benutzer sie finden?
4. Wie stark ist die Funktion betroffen?

Für Priorität:

1. Wie viele Benutzer sind betroffen und welche?
2. Kostet es Geld oder birgt es rechtliche oder Compliance-Risiken?
3. Steht eine Veröffentlichung, Demo oder ein Verkauf an?
4. Wie sichtbar ist es und könnte es Ihrem Ruf schaden?
5. Blockiert es andere Arbeiten, beispielsweise Tests?

Fehlertriage durchführen

Triage ist das regelmäßige Treffen, bei dem ein Team neue Fehler begutachtet und entscheidet, was als nächstes passiert. Ein einfaches Format funktioniert gut:

1. Vorbereiten. Der Tester stellt sicher, dass jeder neue Fehler klare Schritte, Beweise und vorgeschlagenen Schweregrad hat.
2. Bestätigen. Überprüfen Sie, ob es reproduziert werden kann und kein Duplikat ist.
3. Entscheiden. Vereinbaren Sie den Schweregrad, legen Sie eine Priorität fest und weisen Sie einen Eigentümer zu.
4. Schließen Sie den Kreis. Lehnen Sie jeden Fehler ab, verschieben oder planen Sie ihn und notieren Sie den Grund.

Halten Sie es kurz und häufig. In den letzten Tagen vor einer Entlassung ist eine tägliche 15-minütige Triage üblich. Schweregrad und Priorität fließen auch in Ihre Veröffentlichungsentscheidung ein. Vereinbaren Sie daher im Voraus Regeln, wie zum Beispiel „keine offenen S1- oder S2-Fehler bei Veröffentlichung“, als Teil Ihrer Ausstiegskriterien.

Schweregrad und Priorität in einem Fehlerbericht

Ein kurzer, klarer Eintrag hilft jedem, eine gute Entscheidung zu treffen:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Diese Zahlen sind Beispiele. Verwenden Sie in einem echten Bericht gemessene Zahlen aus Ihren Protokollen und erläutern Sie Ihre Argumentation. Erfahren Sie mehr in unserem Leitfaden zum Verfassen eines Fehlerberichts. Es ist auch hilfreich zu wissen, was die Fehlercodes bedeuten. Halten Sie daher unseren Spickzettel mit HTTP-Statuscodes griffbereit.

Häufige Fehler

• Behandeln Sie sie als dasselbe Feld. Wenn die beiden immer übereinstimmen, gehen Ihnen nützliche Informationen verloren.
• Den Schweregrad erhöhen, um Aufmerksamkeit zu erregen. Sobald alles kritisch ist, ist nichts mehr.
• Den Testern die Priorität allein überlassen. Sie haben selten das vollständige Geschäftsbild.
• Überprüfen Sie niemals den Rückstand. Prioritäten veralten, also überprüfen Sie alte Fehler regelmäßig erneut.
• Keine schriftlichen Definitionen. Ohne sie verwenden die Menschen Bezeichnungen anders und am Ende debattiert man über Wörter.
• Anhäufungen geringer Schwere werden ignoriert. Fünfzig kleinere Probleme können dazu führen, dass sich ein Produkt kaputt anfühlt, auch wenn keines für sich genommen schwerwiegend ist.

Fazit

Halten Sie die beiden Fragen getrennt: Wie schlimm ist es und wie schnell muss es behoben werden? Vereinbaren Sie schriftliche Definitionen für jede Ebene und machen Sie deutlich, wer entscheidet. Nehmen Sie im nächsten Schritt die zehn ältesten Fehler in Ihrem Tracker und bewerten Sie sie anhand der oben genannten Fragen neu. Sie werden wahrscheinlich einige finden, die umgezogen werden sollten, und einige, die geschlossen werden sollten.

Häufige Fragen

Lerne weiter