In diesem Ratgeber
Tester verlieren ihre erste Sitzung, wenn das Backend nicht läuft, das Testkonto nicht geht oder die App auf den falschen Server zeigt. Geh diese Liste durch, bevor du eine Einladung schickst. Jeder Punkt hat einen Grund und eine Prüfmöglichkeit.
| # | Punkt | Warum | So prüfst du |
|---|---|---|---|
| 1 | Der Build zeigt auf das Test-Backend, nicht auf Produktion | Testaktionen dürfen keine echten Nutzer oder echtes Geld berühren | Basis-URL im installierten Build prüfen; eine Aktion ausführen und in der Testdatenbank suchen |
| 2 | Das Test-Backend ist von außerhalb deines Netzes erreichbar | Tester sind nicht in deinem WLAN oder VPN | Per Mobilfunk am Handy öffnen |
| 3 | Testkonten für jede Rolle (neu, normal, ggf. Admin) | Tester sollen nicht registrieren oder raten müssen | Mit jedem Konto bei frischer Installation anmelden |
| 4 | Zugangsdaten stehen in der Einladung | Verhindert die erste Support-Frage | Einladung lesen, als wärst du fremd |
| 5 | Testdaten sind realistisch (lange Namen, leere und volle Listen, Sonderzeichen) | Leere oder aufgeräumte Daten verstecken Layout- und Logikfehler | Die Hauptlisten mit diesen Daten durchklicken |
| 6 | Daten lassen sich schnell zurücksetzen | Nach einem misslungenen Lauf brauchst du einen sauberen Stand | Reset einmal ausführen und Zeit nehmen |
| 7 | Zahlungen und E-Mails laufen im Sandbox-/Testmodus | Keine echten Abbuchungen oder Mails an echte Adressen | Einen Testkauf machen; prüfen, wohin Mails gehen |
| 8 | Feature-Flags passen zum getesteten Build | Unfertiges sollte versteckt oder markiert sein | Flags und Werte für diesen Build auflisten |
| 9 | Schlüssel von Drittdiensten (Karten, Push, Login) gelten für den Testbuild | Schlüssel für eine andere App-ID scheitern oft still | Jeden Dienst einmal am Gerät auslösen |
| 10 | Push-Nachrichten kommen auf einem Testgerät an | Wird gern nur in Testbuilds falsch konfiguriert | Eine aus dem Backend senden |
| 11 | Absturz- und Fehlerberichte sind aktiv, mit Build-Nummer | Sonst bekommst du keine Logs von Testern | Einen Test-Absturz auslösen und im Dashboard finden |
| 12 | Logs speichern keine Passwörter oder personenbezogenen Daten | Auch Testdaten können echte Personen betreffen | Stichprobe der Logzeilen lesen |
| 13 | Tester können den Build installieren (Link, Gruppe oder Einladung geht) | Häufigster Fehler zu Beginn | Genau über den Weg der Tester auf einem zweiten Gerät installieren |
| 14 | Die Build-Nummer ist in der App sichtbar | Jede Meldung braucht eine Version | Einstellungen oder Info-Seite öffnen |
| 15 | Eine Liste bekannter Probleme liegt vor | Tester melden nicht, was du kennst | Vor der Einladung schreiben |
| 16 | Es gibt einen Ort für Feedback, den du auch siehst | Verstreutes Feedback geht verloren | Dir selbst einen Testbericht schicken |
Vorlage: Bereitschaftsnotiz vor der Einladung
Umgebung: [Staging-URL] Build: [Nummer] Datum: [Datum]
Geprüft von: [Name]
[ ] Punkte 1-16 erledigt. Ausnahmen: [Liste]
Bekannte Probleme: [Liste]
Reset-Ablauf: [Schritte]
Anpassen
Streiche, was nicht passt (kein Backend, keine Zahlungen). Ergänze Eigenes aus deinem Stack, etwa eine Datenbank-Migration oder einen Demo-Modus mit festen Daten. Zum Testen von Migrationen siehe Datenbank-Migration testen, ohne Nutzerdaten zu verlieren.
Verwandte Seiten
- Übersicht: Checklisten für mobile App-Tests: alle Bereiche an einem Ort
- Checkliste: Datenschutzerklärung für Apps
- Checkliste vor dem App-Launch: 30 Dinge zu prüfen
Steht die Umgebung, kann AppReviewX privates, strukturiertes Feedback von Testern liefern. 1 Feedback = 1 Credit; neue Konten starten mit 0. Kostenlos starten.