Ein Testplan erklärt, was getestet wird, warum, wie, durch wen und unter welchen Bedingungen. Sein Wert liegt im gemeinsamen Verständnis von Vorgehen und Grenzen, nicht in der Länge des Dokuments.
Wann ein Testplan sinnvoll ist
- →Die Funktionalität ist umfangreich, risikoreich oder betrifft mehrere Teams.
- →Umfang, Prioritäten, Umgebungen, Rollen und Bereitschaftskriterien müssen ausdrücklich vereinbart werden.
- →Externe Erwartungen umfassen Audits, Compliance, regulatorische Vorgaben oder formale Berichte.
- →Ohne abgestimmten Plan kann das Team Testtiefe und Grenzen unterschiedlich verstehen.
Was ein guter Plan enthält
- →Testziele und wesentliche Risiken.
- →Einbezogener und ausgeschlossener Umfang.
- →Anwendbare Testarten und Teststufen.
- →Umgebungen, Testdaten und Abhängigkeiten.
- →Rollen, Verantwortlichkeiten, Zeitplanung und Abschlusskriterien.
Was vermieden werden sollte
- →Allgemeine Vorlagen ohne Bezug zum Produkt.
- →Überflüssige Informationen, die niemand nutzt.
- →Ein einmal verfasstes und nie aktualisiertes Dokument.
- →Papierarbeit anstelle tatsächlicher Überlegungen zu Risiken und Strategie.
Praktische Hinweise
Ein guter Plan beantwortet echte Fragen: Was ist kritisch, wo liegen Risiken, was bleibt ungetestet, was fehlt für die Qualität und welche Nachweise unterstützen das Release? Hilft er nicht bei Entscheidungen, ist er zu umständlich oder abstrakt.
Ausgefülltes Beispiel: kleines Release eines Zahlungsformulars
Alles in diesem Plan ist eine fiktive Schulungsannahme. Es ist kein Bericht über eine Bank, einen Kunden oder ein ausgeliefertes Release. Die Anwendung akzeptiert synthetische Zahlungstoken und ruft einen lokalen Anbieter-Stub auf, der approved, declined oder timeout zurückgibt. Es gibt keine echten Kartendaten, Konten oder Geldbeträge. Die Beträge sind ganzzahlige Centwerte in einer ausdrücklich konfigurierten Demo-Währung.
Plan-ID: PAY-DEMO-1; Version: 1; verantwortliche Rolle: QA-Engineer
Ziel: Zahlungsformular prüfen und doppelte erfolgreiche Zahlungen verhindern.
Testobjekt: eingefrorener Demo-Build; tatsächlichen Commit und Konfiguration vor der Ausführung erfassen.
Im Umfang: Absenden, Validierung, Anbieterergebnisse, Wiederholung von Anfragen und Callbacks, Neuladen der Ergebnisseite, Tastaturbedienung und 375-px-Layout.
Außerhalb des Umfangs: echter Anbieter, echte Zahlungsabwicklung, Erstattungen, Abonnements, 3-D Secure, andere Währungen, Last-/Sicherheitszertifizierung.
Umgebung: verwerfbare lokale Anwendung + Anbieter-Stub + Datenbank mit vorbereiteten Testdaten.
Daten: neuer synthetischer Kunde/Auftrag je Testfall; Stub-Protokoll zwischen den Fällen zurücksetzen.
Beobachtung: Anfrage-IDs, Zahlungsprotokoll des Stubs und schreibgeschützte Bestelldaten.
Personen: ein QA-Engineer; Entwickler für Korrekturen verfügbar; Product Owner entscheidet über das akzeptierte Restrisiko.
Schätzung, keine Zusage: zwei Arbeitstage mit je 6 QA-Stunden; 2 Stunden Entwicklerunterstützung und 1 Stunde Review durch den Verantwortlichen.
Ergebnisse: Zuordnung von Anforderungen zu Testfällen, Ausführungsprotokoll, Nachweise ohne sensible Daten, Fehler und Release-Empfehlung.Risikobasierter Umfang mit beobachtbaren Ergebnissen
Die Fälle C01–C08, C11 und C12 sind in diesem Beispiel risikoreich: doppelte Zahlungen, falsche Beträge, falsche Erfolgsmeldungen oder Wiederholungsfehler können den finanziellen Zustand verfälschen. C09–C10 prüfen die Benutzbarkeit und gehören ebenfalls zum Umfang. Die folgenden Erwartungen sind Demo-Anforderungen, kein universelles Verhalten von Zahlungs-APIs.
ID Szenario Erwartet
C01 Token approved Eine bestätigte Bestellung über 1999 Cent; eine akzeptierte Zahlung
C02 Token declined Ablehnungsmeldung; keine bezahlte Bestellung und keine erfolgreiche Zahlung
C03 Token timeout Ausstehend/unbekannt angezeigt; keine automatische zweite Zahlung
C04 gleicher Schlüssel, gleiche Nutzlast zweimal Gleiches gespeichertes Ergebnis; eine Zahlung und eine Bestellung
C05 gleicher Schlüssel, geänderter Betrag Konflikt gemeldet; keine neue Zahlung oder Bestellung
C06 fehlendes Zahlungstoken Feldfehler; keine Zahlungsanfrage
C07 Server erhält Betrag null Durch API abgelehnt; keine Zahlung oder Bestellung
C08 doppelter Callback approved Ein Übergang zu bezahlt; Zahlungsbuch enthält einen Erfolg
C09 nur Tastatur Alle Bedienelemente erreichbar; Absenden und Fehler ohne Maus bedienbar
C10 Viewport 375 px Kein horizontaler Überlauf; Gesamtbetrag und Absendeelement sichtbar
C11 Ergebnisseite neu laden Bestehende Bestellung angezeigt; Zahlung wird nicht erneut gesendet
C12 Transaktion über 1999 Cent prüfen UI, Anfrage und gespeicherte Bestellung stimmen bei Betrag und Währung übereinEingangs-, Unterbrechungs- und Ausgangskriterien
Eingang: alle 12 erwarteten Ergebnisse geprüft; Build-Kennung erfasst; Stub-Modi approved/declined/timeout überprüft; Testkunde angelegt; Zahlungsprotokoll lesbar; Smoke-Test der Umgebung bestanden. Scheitert ein Eingangskriterium, den Blocker dokumentieren, statt den Build als vollständig getestet zu kennzeichnen.
Unterbrechen, wenn das Protokoll nicht verfügbar ist, die Fixture nicht zurückgesetzt werden kann oder beobachtete doppelte Zahlungen die Aussagekraft späterer Fälle gefährden. Nachweise sichern. Fortsetzen, sobald die Ursache behoben ist, der Smoke-Test der Umgebung besteht und betroffene Fälle zurückgesetzt und erneut ausgeführt wurden.
Ausgang für eine Empfehlung: alle 12 Fälle mit Nachweisen ausgeführt; alle 10 Hochrisikofälle bestanden; C09 und C10 bestanden oder dokumentierte Ausnahme eines namentlich benannten Verantwortlichen; keine offenen Fehler, die doppelte erfolgreiche Zahlungen, falsche Beträge oder einen falschen Zahlungsstatus verursachen; jeder behobene Hochrisikofehler nachgetestet und betroffene Regressionstests bestanden. Ausgeschlossene Funktionalität ausdrücklich nennen. Eine Frist allein erfüllt diese Kriterien nicht.
Beispielzeitplan: Tag 1 — Anforderungsprüfung 1h, Umgebung/Daten 1h, Testfallvorbereitung 2h, Ausführung 2h. Tag 2 — restliche Ausführung 2h, Korrekturen und Nachtests 2h, betroffene Regression 1h, Zusammenfassung 1h. Ändert sich das Anbieterverhalten oder wird der Build ersetzt, neu schätzen und betroffene Prüfungen wiederholen; alte „bestanden“-Status nicht stillschweigend übernehmen.
Kopierbare Testplanvorlage
Plan / Version / Verantwortlicher:
Änderung und Geschäftsziel:
Testobjekt / Build / Konfiguration:
Anforderungen und wesentliche Risiken:
Im Umfang / außerhalb des Umfangs:
Umgebung / synthetische Daten / Rücksetzverfahren:
Beobachtungsmechanismen und Nachweise:
Testfall-IDs mit zugeordneten Risiken und erwarteten Ergebnissen:
Rollen / Kapazität / Schätzung / Abhängigkeiten:
Eingangskriterien:
Kriterien für Unterbrechung / Wiederaufnahme:
Ausgangskriterien und Entscheidungsverantwortlicher:
Restrisiken / Ausnahmen / nächster Review-Termin:
Link zum Ausführungsbericht:Dieses Dokument beschreibt auszuführende Arbeit; es behauptet nicht, dass die zwölf Fälle in einer echten Zahlungsanwendung bestanden wurden. Während der Ausführung tatsächliches Ergebnis, Status, Nachweise und Fehlerlinks zu jedem Fall ergänzen. Dem Release-Entscheider sowohl Abdeckung als auch Restrisiko mitteilen, nicht nur eine Erfolgsquote.
Weiterlernen
Release-Plan und Teststrategie verbinden