AppReviewX Anmelden

Testplan-Vorlage für mobile Apps

Ein Plan auf einer Seite: Umfang, Risiken, Geräte, Testarten, Zeitplan und Abschlusskriterien.

aktualisiert ·3 Min. Lesezeit

In diesem Ratgeber

Ein Testplan ist eine aufgeschriebene Entscheidung: was du testest, was nicht, womit, bis wann und wann du aufhörst. Bei einer kleinen App passt er auf eine Seite. Kopiere den Block, fülle jedes Feld aus und lösche, was nicht passt.

Vorlage (zum Kopieren)

TESTPLAN: <App-Name> <Version>
Verantwortlich: <Name>        Datum: <Datum>

1. ZIEL
   Was muss für dieses Release stimmen? (ein bis zwei Sätze)

2. UMFANG
   Im Umfang:     <Funktionen, Abläufe, Plattformen>
   Nicht im Umfang: <was du nicht testest, und warum>

3. GRÖSSTE RISIKEN (was schmerzt am meisten, wenn es kaputt ist)
   1. <Risiko>  -> abgedeckt durch: <Testart>
   2. <Risiko>  -> abgedeckt durch: <Testart>
   3. <Risiko>  -> abgedeckt durch: <Testart>

4. GERÄTE UND OS
   <Gerät / OS-Version / warum auf der Liste>
   <Gerät / OS-Version / warum auf der Liste>

5. TESTARTEN
   [ ] Smoke-Test bei jedem Build
   [ ] Tests der Kernabläufe (Registrierung, Hauptaufgabe, ggf. Bezahlung)
   [ ] Regressionsliste
   [ ] Explorative Sessions (wer, wie lange)
   [ ] Unterbrechungen, Offline, Berechtigungen
   [ ] Barrierefreiheit (Grundlagen)
   [ ] Text- und Übersetzungsdurchgang

6. TESTER
   <wer, wie viele, was sie bekommen, wie sie berichten>

7. ZEITPLAN
   Build fertig: <Datum>   Test: <von - bis>   Korrekturen: <bis>   Entscheidung: <Datum>

8. UMGANG MIT FEHLERN
   Wo Fehler erfasst werden: <Ort>
   Schweregrad-Skala: <Link oder Kurzdefinition>

9. ABSCHLUSSKRITERIEN (wann der Test fertig ist)
   - Kein offener Fehler ab Schweregrad <Stufe>
   - Alle Kernabläufe bestehen auf <Geräte>
   - <eigene Bedingung>

10. ENTSCHEIDUNG
    Go / No-go: <Entscheidung>   Grund: <kurz>

Beispiel (zur Veranschaulichung, kein echtes Projekt)

TESTPLAN: Beispiel-Gewohnheitstracker 1.4
Verantwortlich: Sam          Datum: 2026-11-02

1. ZIEL
   Erinnerungen kommen zuverlässig, und bestehende Daten überstehen das Update.

2. UMFANG
   Im Umfang:       Erinnerungen, Gewohnheitsliste, Backup/Wiederherstellung, Android 12-15
   Nicht im Umfang: Tablet-Layout (nicht unterstützt), Widget (unverändert)

3. GRÖSSTE RISIKEN
   1. Erinnerungen feuern nach Neustart nicht -> explorativ + Neustart-Test
   2. Datenverlust beim Update                -> Update-Test ab 1.3
   3. Absturz beim ersten Start               -> Smoke-Test

4. GERÄTE UND OS
   Mittelklasse-Handy / Android 13 / häufigste Version bei unseren Nutzern
   Älteres Handy / Android 10 / niedrigste unterstützte Version

...
9. ABSCHLUSSKRITERIEN
   - Kein offener Absturz- oder Datenverlust-Fehler
   - Smoke-Test und Erinnerungsablauf bestehen auf beiden Geräten

So passt du sie an

  • Einzelentwickler: Behalte die Abschnitte 1, 3, 4, 9. Den Rest je in einer Zeile.
  • Build an externe Tester geben: Schreibe in Abschnitt 6, was sie ausprobieren sollen; für die Auswertung danach siehe die Testbericht-Vorlage.
  • Geräte nach Risiko wählen, nicht nach Menge. Nimm das älteste unterstützte OS, ein verbreitetes Mittelklasse-Gerät und einen kleinen Bildschirm. Stütze dich nur auf Wissen, das du über deine Nutzer wirklich hast.
  • Updates einer Live-App: Ergänze einen Test "Update von der letzten Version". Siehe Update einer Live-App testen.
  • Geschlossener Test bei Google Play: Plane Testergruppe und Dauer nach der aktuellen Google-Play-Anforderung. Zum Zeitpunkt der Prüfung nennt die Play-Console-Hilfe für private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, mindestens 12 Tester, die in den letzten 14 Tagen durchgehend teilgenommen haben, bevor du Produktivzugang beantragen kannst; lies die aktuelle Seite für dein Konto. Siehe geschlossener Test mit 12 Testern.
  • Abschlusskriterien müssen prüfbar sein. "Fühlt sich stabil an" ist keins.

Weiterlesen

Du brauchst Tester und eine strukturierte Art, ihre Funde zu sammeln? Starte bei AppReviewX.