In diesem Ratgeber
Ein Smoke-Test beantwortet eine Frage: Ist dieser Build die Zeit anderer wert? Er ist eine schnelle Schranke, kein vollständiger Test. Schlägt eine Prüfung fehl, halte an, behebe es und baue neu. Gib keinen Build an Tester, der beim Start abstürzt.
Führe ihn auf einem echten Gerät aus, mit genau der Build-Datei, die du weitergeben willst (nicht mit einem Debug-Lauf aus der Entwicklungsumgebung).
Vorlage (zum Kopieren)
SMOKE-TEST: <App-Name> Build <Nummer> Datum: <Datum>
Gerät / OS: <Gerät, Version> Prüfer: <Name>
Beim ersten Fehler anhalten.
[ ] 1. Installiert sauber (frische Installation, kein Update)
[ ] 2. Startet ohne Absturz oder leeren Bildschirm
[ ] 3. Angezeigte Version und Build-Nummer sind die erwarteten
[ ] 4. Startscreen lädt mit echten oder Testdaten
[ ] 5. Registrierung oder Anmeldung funktioniert (Testkonto)
[ ] 6. Die eine Kernaktion klappt von Anfang bis Ende: <benennen>
[ ] 7. Daten bleiben nach Schließen und Neuöffnen erhalten
[ ] 8. Zurück-Navigation und App-Wechsel zerstören den Screen nicht
[ ] 9. Offline: App öffnet und zeigt eine sinnvolle Meldung, kein Absturz
[ ] 10. Release-Build zeigt auf das richtige Backend / die richtige Konfiguration (nicht Test oder lokal)
Ergebnis: BESTANDEN / FEHLGESCHLAGEN (Punkt: __ )
Notizen:
Warum diese zehn, und wie du prüfst
- Frische Installation. Updates verstecken Installationsprobleme. So prüfst du: vorher deinstallieren.
- Start. Abstürze beim Start sind der häufigste Build-Killer. So prüfst du: zweimal starten, einmal kalt.
- Version und Build-Nummer. Fängt die falsche Datei ab. So prüfst du: mit deinen Notizen vergleichen.
- Startscreen. Kaputte oder leere Datenschichten fallen hier zuerst auf. So prüfst du: warten, bis alles geladen ist.
- Registrierung oder Anmeldung. Ohne sie kommen die meisten Tester nicht weiter. So prüfst du: ein vorbereitetes Testkonto nutzen.
- Eine Kernaktion. Beweist, dass der Daseinszweck des Produkts noch geht. So prüfst du: in der Vorlage benennen und einmal ausführen.
- Speichern. Speicherfehler sind teuer. So prüfst du: App beenden, neu öffnen, Daten suchen.
- Navigation. Ein kaputter Zurück-Stapel nervt sofort. So prüfst du: Zurück, Home, Rückkehr.
- Offline. Echte Nutzer verlieren das Netz. So prüfst du: Flugmodus, dann starten.
- Konfiguration. Mit einer Test-Serveradresse auszuliefern ist ein Klassiker. So prüfst du: Umgebungsanzeige oder Log ansehen oder eine Anfrage senden, die du nachprüfen kannst.
Beispiel (zur Veranschaulichung)
SMOKE-TEST: Beispiel-Notizen-App Build 87 Datum: 2026-11-04
Gerät / OS: Mittelklasse-Handy, Android 13 Prüfer: Sam
[x] 1 [x] 2 [x] 3 [x] 4 [x] 5
[ ] 6. Kernaktion: Notiz anlegen und speichern -> FEHLER: Speichern-Button reagiert nicht
Ergebnis: FEHLGESCHLAGEN (Punkt 6). Build nicht weitergegeben.
So passt du sie an
- Ersetze Punkt 6 durch deine Kernaktion und ergänze eine Zeile, falls es eine zweite Pflichtfunktion gibt (etwa einen Kauf).
- Bleib bei zehn Punkten. Dauert es länger als fünf Minuten, verschiebe Extras in die Regressionsliste.
- Automatisiere später, wenn überhaupt. Ein manueller Durchlauf reicht, bis du sehr oft baust.
Weiterlesen
- Übersicht: Checklisten für mobile App-Tests
- Vorlage: Charta für exploratives Testen
- Matrix für Schweregrad und Priorität von Fehlern
Build bestanden? Starte kostenlos und hole dir privates, strukturiertes Feedback dazu.