Fehler passieren. Entscheidend ist, ob Nutzer verstehen, was los ist, und wieder herauskommen. Löse die Fehler auf jedem Bildschirm, der Daten lädt oder sendet, gezielt aus: Flugmodus, wackelige Verbindung oder in einem Testbuild ein gesperrtes Backend.
Die Checkliste
- Keine Verbindung beim Öffnen. - Warum: Viele Apps werden zum ersten Mal in schlechtem Netz geöffnet. - So prüfst du: Flugmodus, Kaltstart. Ein klarer Zustand „keine Verbindung“ erscheint, kein leerer Bildschirm und kein endloser Spinner.
- Verbindung bricht mitten in der Aktion ab. - Warum: Halb gesendete Aktionen verlieren oder verdoppeln Daten. - So prüfst du: Speichern oder Senden starten, dann Flugmodus an. Die App meldet den Fehlschlag und behält die Eingabe.
- Serverfehler (5xx). - Warum: Das Backend fällt mal aus, und das ist nicht Schuld der Nutzer. - So prüfst du: Testbuild auf einen fehlerhaften Endpunkt zeigen lassen. Die Meldung sagt, dass es bei dir liegt, und rät zum erneuten Versuch.
- Inhalt nicht gefunden oder entfernt. - Warum: Elemente werden gelöscht, während ein Link oder Bildschirm noch offen ist. - So prüfst du: Element öffnen, auf einem anderen Gerät löschen, dann hier eine Aktion ausführen. Die App zeigt eine klare Meldung und einen Rückweg.
- Abgelaufene Sitzung. - Warum: Stille Abmeldungen und kryptische Fehler vertreiben Nutzer. - So prüfst du: Token ungültig machen oder Ablauf abwarten. Die App bittet um erneute Anmeldung und führt danach zurück.
- Berechtigung verweigert. - Warum: Nutzer lehnen Kamera, Standort oder Benachrichtigungen ab. - So prüfst du: Berechtigung ablehnen, dann die Funktion nutzen. Die App erklärt, was nötig ist, und verlinkt auf die Einstellungen.
- Wortlaut der Meldungen. - Warum: Codes und Stacktraces sagen Nutzern nichts. - So prüfst du: Jede Meldung lesen. Sie sagt in einfacher Sprache, was passiert ist, ohne interne Codes.
- Ton und Schuldzuweisung. - Warum: „Du hast falsche Daten eingegeben“ wirkt feindselig, wenn der Server schuld ist. - So prüfst du: Bei jeder Meldung fragen, wer schuld ist und ob der Text das widerspiegelt.
- Bei jedem Fehler gibt es einen Ausweg. - Warum: Sackgassen enden im Beenden der App. - So prüfst du: Jeder Fehler hat eine funktionierende Schaltfläche (Wiederholen, Zurück, Kontakt). Teste auch Zurücktaste und Wischgeste.
- „Wiederholen“ wiederholt wirklich.
- Warum: Eine Schaltfläche ohne Wirkung ist schlimmer als keine.
- So prüfst du: Fehlschlagen lassen, Verbindung wiederherstellen, Wiederholen tippen. Die Aktion läuft einmal durch, ohne Duplikat.
- Fehler erscheinen nicht doppelt oder gestapelt.
- Warum: Drei Dialoge für einen Fehler überfordern.
- So prüfst du: Auf einem Bildschirm mit mehreren Anfragen einen Fehler auslösen. Es erscheint eine klare Meldung.
- Fehler erreichen Hilfstechnologien.
- Warum: Reine Toast-Meldungen verschwinden für Screenreader-Nutzer.
- So prüfst du: Mit Screenreader einen Fehler auslösen; er wird vorgelesen und ist erreichbar. Siehe Screenreader-Test in 10 Minuten.
- Offline-Verhalten ist bewusst gewählt.
- Warum: Manche Aktionen sollten in die Warteschlange, andere blockieren.
- So prüfst du: Folge Offline-Verhalten testen und notiere, was jeder Bildschirm tut.
- Wiederherstellung nach Absturz.
- Warum: Nach einem Absturz sollten Nutzer an einem sinnvollen Ort landen.
- So prüfst du: Mitten in einer Aktion beenden und neu öffnen. Kein beschädigter Zustand, keine Absturzschleife.
- Fehler hinterlassen eine Spur für dich.
- Warum: Was du nicht siehst, kannst du nicht beheben.
- So prüfst du: Nach den ausgelösten Fehlern kontrollieren, ob dein Logging oder Absturz-Tool sie ohne personenbezogene Daten erhalten hat.
Verwandt
Alle Checklisten · Leere Zustände testen · Ladezustände testen
Wenn eine Fehlermeldung einen Tester verwirrt, willst du es vor der Store-Bewertung erfahren. Bei AppReviewX loslegen: privates, strukturiertes Feedback, 1 Feedback = 1 Credit.