Glossar · Testgrundlagen
Fehlerpriorität
Englisch: Bug priority
Auch genannt: Bug-Priorität, Priorität, Defect Priority, Prioritätsstufen
Definition
Wie dringend ein Fehler im Vergleich zu anderer Arbeit behoben werden soll, entschieden nach geschäftlichem Bedarf – meist vom Product Owner oder in der Bug-Triage.
Die Fehlerpriorität beschreibt, in welcher Reihenfolge Fehler behoben werden. Sie ist eine geschäftliche Entscheidung, die Auswirkungen auf Nutzer, Deadlines, Kundenzusagen, Reputation und die Kosten der Korrektur abwägt. Tester können eine Priorität vorschlagen, die endgültige Entscheidung liegt aber meist beim Product Owner, oft in einem Triage-Meeting mit Entwicklung und QA.
Typische Skala
| Priorität | Bedeutung |
|---|---|
| P1 / Dringend | Sofort beheben, ggf. per Hotfix außerhalb des regulären Releases |
| P2 / Hoch | Im aktuellen Sprint oder vor dem nächsten Release beheben |
| P3 / Mittel | Für einen späteren Sprint einplanen |
| P4 / Niedrig | Bei Gelegenheit beheben oder akzeptieren und schließen |
Priorität vs. Schweregrad
Der Schweregrad misst die Auswirkung: wie stark das Produkt beeinträchtigt ist. Die Priorität misst die Dringlichkeit: wie bald der Fehler behoben werden muss. Beide werden getrennt bewertet, weil sie oft auseinanderliegen.
- Niedriger Schweregrad, hohe Priorität: ein falscher Preis in einem Banner für eine Kampagne, die morgen startet. Nichts stürzt ab, aber vor dem Start muss es stimmen.
- Hoher Schweregrad, niedrige Priorität: ein Absturz in einem Admin-Report, der nur zum Jahresende läuft – in elf Monaten.
Außerdem ändert sich die Priorität mit der Zeit, der Schweregrad meist nicht. Derselbe Jahresend-Absturz wird im Dezember zu P1.
Wie die Priorität entschieden wird
Hilfreiche Fragen in der Triage:
- Wie viele Nutzer sind betroffen, und welche (zahlende Kunden, interne Mitarbeiter, ein einzelner Mandant)?
- Gibt es einen Workaround, und kann der Support ihn erklären?
- Gibt es einen Release-, Demo-, rechtlichen oder vertraglichen Termin?
- Welche Kosten und Risiken hat die Korrektur selbst? Ein riskanter Fix spät im Release wird mitunter bewusst verschoben.
Häufige Fehler
- Ein Feld für beides. Teams, die nur „Priorität“ erfassen, verlieren die Information über die Auswirkung, die für Release-Risiko und Metriken wichtig ist.
- Alles ist P1. Wenn fast jeder Bug dringend ist, ist es keiner. Halten Sie die höchste Stufe selten und klar definiert.
- Priorität nie überprüfen. Bewerten Sie offene Bugs neu, wenn sich der Release-Plan oder die Kundensituation ändert.