Checkliste für mobile Tests

Eine mobile Checkliste hält wichtige Risiken vor einem Release zwischen Dutzenden Ansichten und Geräten sichtbar. Jede Prüfung verbindet eine konkrete Handlung mit einem beobachtbaren Ergebnis. „Netzwerk prüfen“ ist zu breit; „nach dem Absenden einer Bestellung trennen und prüfen, dass ein Retry keine zweite Bestellung erzeugt“ kann einen Fehler aufdecken.

Verwenden Sie dieses Material als anpassbaren Ausgangspunkt. Banking-App, Medienplayer und Gewohnheitstracker benötigen unterschiedliche Tiefe und Schwerpunkte. Eine gute Checkliste entsteht aus Produkt, Nutzungsdaten, Releaseänderungen und früheren Vorfällen.

Umfang des Testlaufs festlegen

Dokumentieren Sie vorher Version und Buildnummer, API-Umgebung, Installationsart, Feature-Flags und Testkonten. Erstellen Sie eine kurze Gerätematrix: wichtige OS-Version, kleinste unterstützte Konfiguration, verbreitete Bildschirmgröße und ein ressourcenarmes Gerät. Wählen Sie anhand von Benutzern und Risiken und benennen Sie Auslassungen ausdrücklich.

Trennen Sie Smoke-Tests von erweiterter Regression. Smoke-Tests klären, ob ein Build für weitere Arbeit verwendbar ist und wesentliche Abläufe funktionieren. Sie ersetzen weder Datenmigrationstests noch Prüfungen nach mehrstündiger Nutzung.

Installation, Updates und erster Start

Prüfen Sie eine Neuinstallation und ein Update von einer unterstützten Vorversion. Legen Sie vorher realistische Appdaten an: Entwurf, Einstellungen und Offlineobjekte. Nach dem Update müssen sie gemäß Anforderungen erhalten oder migriert sein.

Prüfen Sie beim ersten Start Onboarding, Sprachwahl, notwendige Einwilligung und Zugang zum Hauptbildschirm bei verweigerten optionalen Berechtigungen. Prüfen Sie nach Deinstallation und Neuinstallation die Datenwiederherstellung gemäß Plattform- und Produktregeln; ein weiterhin bestehendes Serverkonto beweist keinen Deinstallationsfehler.

Kritische Benutzerabläufe

Identifizieren Sie wichtige Nutzungsgründe: Anmelden, Suchen, Bestellen, Nachrichten senden oder Tickets ansehen. Prüfen Sie jeweils den Erfolgsfall und mindestens einen Fehlerzustand.

→Die Aktion verändert tatsächlich Serverdaten; erneute Anmeldung zeigt den gespeicherten Zustand.
→Eine leere Liste erklärt den nächsten Schritt; Fehler erlauben die Fortsetzung.
→Doppeltippen und wiederholtes Senden erzeugen keine verbotenen Duplikate.
→Tastatur, lange Texte und Systemflächen verdecken keine erforderliche Aktion.

Ergebnisprüfung ist wichtiger als die Anzahl geöffneter Ansichten. Eine korrekt angezeigte Toastmeldung beweist keine Speicherung der Anfrage.

Netzwerk- und Offlinezustände

Prüfen Sie Start ohne Netzwerk, Verbindungsverlust beim Lesen und Schreiben, langsame Antworten, Wiederverbindung und Wechsel von WLAN zu Mobilfunk. Klären Sie Verhalten eingereihter lokaler Operationen und Regeln zur Konfliktlösung.

Klären Sie bei Operationen mit Nebenwirkungen den Fall, dass der Server fertig ist, der Client aber keine Antwort erhält. Die Anzeige darf weder unbestätigten Erfolg melden noch endlose Wiederholungen erzwingen. Vergleichen Sie nach Wiederverbindung lokalen und Serverzustand und suchen Sie nach Duplikaten.

Lebenszyklus und Systemunterbrechungen

Schicken Sie die App bei offenem Formular in den Hintergrund, öffnen Sie sie erneut, sperren Sie das Gerät und kehren Sie nach Sitzungsablauf zurück. Prüfen Sie Neuerstellung der Ansicht und Prozessbeendigung getrennt vom gewöhnlichen Hintergrundwechsel: Die Wiederherstellungsbedingungen unterscheiden sich.

Anforderungen können Entwürfe erhalten und sensible Daten gleichzeitig verbergen lassen. Das System darf keine bestätigte Operation verlieren oder mit veralteten Berechtigungen fortsetzen. Prüfen Sie auch eingehende Anrufe oder Systemdialoge während Audioaufnahme, Zahlung oder Upload, sofern das Produkt diese Szenarien unterstützt.

Prüfen Sie Erteilen, Verweigern und späteres Entziehen benötigter Berechtigungen. Die App soll fehlenden Kamera-, Standort- oder Benachrichtigungszugang klar behandeln. Unbenutzte Berechtigungen nur der Vollständigkeit halber aufzunehmen ist unnötig.

Prüfen Sie Push-Mitteilungen im Vordergrund, Hintergrund und beim Start durch eine Mitteilung. Testen Sie Deep Links bei installierter App, abgelaufener Sitzung, nicht verfügbarem Objekt und erneutem Öffnen. Nach Kontowechsel darf keine Mitteilung fremde Daten zeigen; Navigation darf Zugriffskontrollen nicht umgehen.

Daten, Sicherheit und Kompatibilität

Prüfen Sie mit zwei Testkonten Benutzerwechsel, Abmeldung und Zugang zu zuvor geöffneten privaten Ansichten. Caches, Suche und Push-Mitteilungen dürfen keine Daten des vorherigen Benutzers mehr offenlegen. Diagnoselogs und Berichte dürfen keine echten Tokens oder Benutzergeheimnisse enthalten.

Prüfen Sie unterstützte Sprachregionen, Zeitzonen und Datumsformate in relevanten Szenarien. Mitternachtswechsel sind bei Buchungen, Zeitplänen und Tageslimits besonders hilfreich. Wiederholen Sie die riskantesten Szenarien auf weiteren Geräten unter Berücksichtigung der konkreten Releaseänderung.

Barrierefreiheit, Geschwindigkeit und Stabilität

Durchlaufen Sie den Hauptablauf mit TalkBack oder VoiceOver, vergrößertem Text und vereinbarten Systemeinstellungen. Bewerten Sie Erreichbarkeit von Schaltflächen, Fokusreihenfolge und Fehlermeldungen. Automatische Scanner ergänzen manuelle Tests.

Vergleichen Sie für Performance Kaltstart und Hauptoperation mit einer akzeptierten Referenzversion in derselben Umgebung. Dokumentieren Sie Messmethode und mehrere Wiederholungen. Prüfen Sie Hänger, Abstürze, Speicherwachstum nach wiederholten Aktionen und Aktivität im Hintergrund; „wirkt schnell“ genügt nicht.

Praxisbeispiel: Smoke-Test einer Liefer-App

Angenommen, das Team vereinbart fünf Pflichtprüfungen für einen neuen Build: Update, Anmeldung, Warenkorb, Bestellbestätigung und Öffnen aus einer Benachrichtigung. Aktualisieren Sie auf dem Hauptgerät die Vorversion mit gespeicherter Adresse, melden Sie sich an, legen Sie ein Item in den Warenkorb, bestellen Sie testweise und öffnen Sie die Mitteilung.

Erwartet: Adresse bleibt erhalten, Beträge stimmen in jedem Schritt, genau eine Bestellung entsteht, die Mitteilung öffnet diese Bestellung und es gibt keinen Absturz. Wiederholen Sie die Bestätigung separat mit verlorener Antwort und anschließender Netzwerkwiederherstellung. Prüfen Sie auf einem zweiten Gerät Anmeldung und Bestellabschluss. Dieser Lauf hat klare Grenzen; die Zahl bestandener Punkte macht ihn nicht zur vollständigen Regression.

Ergebnisse berichten

Verwenden Sie je Punkt Passed, Failed, Blocked oder Not Run mit Umgebung und Defektlink. Blocked bedeutet, dass die Prüfung nicht möglich war, nicht dass sie bestanden ist. Nennen Sie Blocker und ungetestete Risiken, etwa ein noch ungeprüftes Update auf der ältesten unterstützten OS-Version.

Eine Checkliste ist hilfreich, wenn sie eine Buildentscheidung unterstützt. Pflegen Sie sie nach Vorfällen und Produktänderungen, entfernen Sie Duplikate und automatisieren Sie stabile wiederholbare Prüfungen. Jeder Punkt sollte exakt erklären, was zu beobachten ist und warum es wichtig ist.

Weiterführende Informationen

Die Checkliste in eine Matrix aus Funktion × Plattform × Zustand überführen

Wählen Sie Geräte anhand unterstützter OS-Versionen, tatsächlicher Produktnutzung sofern vorhanden und Risiken wie Speicherdruck, kleinen Bildschirmen und Hardwarefunktionen. Ohne Produktanalytik ist ein Vorschlag mit drei Geräten eine Risikohypothese, keine gemessene Marktabdeckung: älteste unterstützte Android-Konfiguration, aktuelle Android-Konfiguration eines anderen Herstellers und unterstütztes iPhone. Ergänzen Sie iPhone-OS- und Bildschirmvarianten, wenn Unterstützungsumfang oder Funktionsrisiko dies rechtfertigen.

plain text

Funktion	Plattform/Zustand	Aktion	Erwartete Beobachtung	Nachweis
Formularentwurf	Android Hintergrund/Rückkehr	Text eingeben, App wechseln, zurückkehren	Zustand folgt vereinbarter Speicherregel; kein doppeltes Absenden	Build + Video
Formularentwurf	iOS inaktiv/Hintergrund/Rückkehr	Bearbeitung unterbrechen, zurückkehren	Zustand folgt vereinbarter Speicherregel	Build + Video
Kamera	Jede Plattform; Berechtigung verweigert	Funktion aufrufen und Anfrage ablehnen	Nutzbare Alternative; klare Erklärung; kein Absturz	Berechtigungszustand + Video
Gespeicherte Liste	Jede Plattform; offline/wieder verbunden	Laden, trennen, aktualisieren, wieder verbinden	Cache und Wiederholung folgen den Anforderungen	Netzwerkmitschnitt + UI
Deep Link	Jede Plattform; Kalt-/Warmstart	Link angemeldet/abgemeldet öffnen	Richtiges Ziel oder sicherer Anmeldeablauf	Link + Sitzungszustand
Upgrade	Jeder unterstützte Aktualisierungspfad	Neuen Build über vorbereiteten alten Zustand installieren	Erforderliche Daten erhalten und migriert	Alter/neuer Build + Datenvergleich

Setzen Sie Android-Activity-Callbacks nicht mit iOS-Scene-Übergängen gleich. Android-Activities können neu erzeugt werden; iOS-Vordergrund- und Hintergrundverhalten folgt dem Scene- oder App-Lebenszyklus. Dokumentieren Sie tatsächliches OS, Lebenszyklusaktion und beobachtete Wiederherstellung. Verweigerung und späteres Entziehen einer Berechtigung in den Einstellungen sind getrennt zu prüfen; die Optionen hängen von OS-Version und Berechtigungstyp ab.

Dokumentieren Sie je Zeile Pass/Fail/Blocked/Not run, genaues Gerät und OS, App-Build, Ausgangszustand und einen bereinigten Beleglink. Ein Simulator allein belegt kein Verhalten echter Kameras, Mitteilungszustellung, Funkwechsel oder realen Speicherdrucks. Wählen Sie Tests auf echten Geräten nach Funktionsrisiko statt vollständige Konfigurationsabdeckung zu behaupten.