PlayStore12Tester
ENTWICKLERHANDBUCH

So testen Sie eine Android-App vor der Veröffentlichung

Ein Release-Testplan verbindet Ihre wichtigen Benutzerreisen mit einem bestimmten Build, repräsentativen Geräten und aufgezeichneten Ergebnissen. Nutzen Sie die Checkliste als Ausgangspunkt und passen Sie sie dann an die App und das Risiko der Änderung an.

Definieren Sie den Release Candidate und den Umfang

Wählen Sie den genauen Build aus, den Sie versenden möchten, und notieren Sie, was sich geändert hat. Listen Sie die wichtigsten Reisen, die unterstützten Android-Versionen und Formfaktoren sowie alle von der Änderung betroffenen Integrationen auf. Vereinbaren Sie, welche Bereiche ausgeschlossen sind.

Wählen Sie eine repräsentative Testmatrix

Wählen Sie Geräte und Android-Versionen basierend auf Ihrer unterstützten Zielgruppe, den verfügbaren Nutzungsdaten und der von Ihnen vorgenommenen Änderung aus. Beziehen Sie nach Möglichkeit neben Emulatoren auch relevante reale Geräte ein. Ein positives Ergebnis für eine Konfiguration stellt nicht die Abdeckung aller Geräte sicher.

Führen Sie zunächst einen kurzen Rauchtest durch

Bestätigen Sie die Installation, den Start und eine vollständige Kernreise, bevor Sie Zeit mit dem vollständigen Plan verbringen. Wenn ein Blockierungsproblem sinnvolle Tests verhindert, melden Sie es anhand des genauen Builds und wiederholen Sie den Rauchtest nach der Behebung.

Testen Sie Übergänge und Fehlerpfade

Überprüfen Sie das Neuinstallations- und Aktualisierungsverhalten, Berechtigungsoptionen, ungültige Eingaben und unterbrochenen Netzwerkzugriff. Übung im Hintergrund und Rückkehr zur App. Für App-spezifische Käufe oder Kontoflüsse nutzen Sie geeignete Testumgebungen und dedizierte Konten.

Überprüfen Sie Bildschirm- und Zugänglichkeitsvarianten

Überprüfen Sie das kleinste unterstützte Fenster, großen Text, unterstützte Ausrichtungen und relevante Sprachen. Beziehen Sie bei der Bewertung der Barrierefreiheit eine manuelle TalkBack-Reise ein. Automatisierte Prüfungen und manuelle Verwendung offenbaren unterschiedliche Probleme. Keines von beiden allein stellt eine vollständige Zugänglichkeit her.

Notieren Sie die Ergebnisse, bevor Sie eine Freigabeentscheidung treffen

Markieren Sie einen Scheck erst dann als bestanden, wenn Sie das erwartete Ergebnis beobachtet haben. Erfassen Sie fehlgeschlagene Prüfungen mit Berichtsreferenzen, belassen Sie ungeprüfte Prüfungen als nicht geprüft und erläutern Sie, warum ein Element nicht anwendbar ist. Besprechen Sie die Fehlerbehebungen und verbleibenden Risiken mit der für den Versand verantwortlichen Person.

Beispiel: ein geänderter Anmeldeablauf

Anschauliches Planungsbeispiel: Eine Anmeldeänderung wirkt sich auf neue Anmeldungen, ungültige Anmeldeinformationen, abgelaufene Sitzungen, Offline-Wiederholungen und die Rückkehr aus dem Hintergrund aus. Fügen Sie die unterstützten Sprach- und Großtextvarianten hinzu, die für diesen Bildschirm am relevantesten sind. Zeichnen Sie jedes Ergebnis im Vergleich zum Kandidaten-Build auf.

Halten Sie die Berechtigung QA und Google Play getrennt

Diese Checkliste hilft bei der Organisation von Qualitätsprüfungen. Es handelt sich nicht um eine offizielle Google-Zertifizierung, ein Sicherheitsaudit oder einen Nachweis, dass eine Google Play-Testerteilnahmevoraussetzung erfüllt wurde. Die Produktionsberechtigung für Google Play ist ein separater Prozess.

Häufig gestellte Fragen

Bedeutet das Ausfüllen der Checkliste, dass die App versandbereit ist?

Nein. Es werden nur die von Ihnen durchgeführten Prüfungen zusammengefasst. Die Freigabeentscheidung hängt auch von ungelösten Problemen, ausgeschlossenen Bereichen und den Bedürfnissen Ihrer Benutzer ab.

Wie viele Geräte soll ich testen?

Es gibt keine allgemeingültige Zählung, die den Versicherungsschutz belegt. Wählen Sie repräsentative Konfigurationen für Ihre unterstützte Zielgruppe und dokumentieren Sie die Grenzen Ihrer Testmatrix.

Kann ich die Checkliste ohne JavaScript nutzen?

Ja. Die vollständige Checkliste befindet sich im HTML der Seite und kann ausgedruckt werden. Interaktive Status und Markdown-Export erfordern JavaScript.

Quellen und weiterführende Literatur