In diesem Ratgeber
Zwei Wörter werden ständig vermischt. Schweregrad sagt, wie schlimm der Fehler für den Nutzer ist: was kaputt geht. Priorität sagt, wie bald du ihn behebst: eine Entscheidung, die auch davon abhängt, wie viele betroffen sind, wie leicht eine Umgehung ist und wann dein Release ansteht. Als Einzelentwickler definierst du beides einmal, damit derselbe Fehler am Montag und am Freitag gleich bewertet wird.
Schweregrade (kopieren und anpassen)
S1 Kritisch Die App stürzt ab, Daten gehen verloren oder werden beschädigt, Geld wird
falsch abgebucht oder ein Kernablauf lässt sich nicht abschließen. Keine Umgehung.
S2 Schwer Eine Kernfunktion ist kaputt oder kaum nutzbar, aber es gibt eine Umgehung.
S3 Leicht Eine Nebenfunktion verhält sich falsch oder eine Kernfunktion in einem Randfall.
S4 Trivial Kosmetisch: Tippfehler, schiefe Ausrichtung, kleiner optischer Fehler.
Reichweite (wie viele betroffen sind)
Viele Die meisten oder alle Nutzer auf einem verbreiteten Gerät / OS / Ablauf
Einige Eine klar abgrenzbare Gruppe (eine Gerätefamilie, eine Sprache, eine Kontoart)
Wenige Seltene Bedingungen oder ein einzelner gemeldeter Fall
Die Matrix
Priorität aus Schweregrad (Zeilen) und Reichweite (Spalten):
| Viele | Einige | Wenige | |
|---|---|---|---|
| S1 Kritisch | P0: sofort beheben, Release stoppen | P0: sofort beheben | P1: vor dem Release beheben |
| S2 Schwer | P1: vor dem Release beheben | P1: vor dem Release beheben | P2: nächstes Release |
| S3 Leicht | P2: nächstes Release | P2 oder P3 | P3: Backlog |
| S4 Trivial | P3: Backlog | P3: Backlog | P3: Backlog oder schließen |
Bedeutung der Prioritäten: P0 alles andere stehen lassen. P1 muss vor diesem Release raus. P2 für das nächste Release einplanen. P3 Backlog, beheben wenn man in der Nähe ist.
Vorlage zum Bewerten eines Fehlers (zum Kopieren)
FEHLER: <Titel>
Schweregrad: S<1-4> Reichweite: <viele / einige / wenige> Priorität: P<0-3>
Umgehung: <ja: beschreiben / nein>
Begründung: <ein Satz>
Entscheidung: <sofort / vor Release / nächstes Release / Backlog> Datum: <Datum>
Beispiel (zur Veranschaulichung)
FEHLER: App stürzt beim Speichern mit leerem Titel ab
Schweregrad: S1 Reichweite: Einige (nur Nutzer, die das Titelfeld auslassen) Priorität: P0
Umgehung: Titel eingeben
Begründung: Absturz mit Datenverlust bei der wichtigsten Speicheraktion; die Umgehung beseitigt den Absturz nicht.
Entscheidung: sofort beheben Datum: 2026-11-05
So passt du sie an
- Weiche mit Begründung ab. Regeln gelten für die 90 Prozent; schreibe auf, warum du eine gebrochen hast.
- Hebe die Priorität bei Risiken außerhalb der Matrix an: Sicherheits- und Datenschutzprobleme, Zahlungsfehler und alles, was gegen Store-Regeln verstoßen könnte, sollten nicht warten. Prüfe bei Letzterem die aktuellen Richtlinien.
- Nutze echte Daten, wenn du sie hast. Absturzberichte zeigen die Reichweite; siehe Absturzberichte priorisieren und App-Feedback priorisieren.
- Höchstens vier Stufen. Mehr Stufen bedeuten mehr Streit, keine besseren Entscheidungen.
- Sag Testern, was du meinst, damit ihre Schweregrad-Einschätzung zu deiner passt; die Entscheidung bleibt bei dir.
Weiterlesen
- Übersicht: Checklisten für mobile App-Tests
- Liste bekannter Fehler für Tester
- Go-/No-go-Checkliste für den Release
Starte kostenlos, sammle Fehlerberichte strukturiert und bewerte sie mit dieser Matrix.