Glossar · Testgrundlagen
Testplan
Englisch: Test plan
Auch genannt: Testkonzept, Testplanung, IEEE 829
Definition
Ein Dokument, das Umfang, Vorgehen, Ressourcen, Zeitplan, Umgebungen, Risiken sowie Eingangs- und Endekriterien für das Testen eines Releases oder Projekts festlegt.
Ein Testplan beschreibt, wie für ein bestimmtes Release, Projekt oder Feature getestet wird: was im Umfang ist und was nicht, welche Testarten zum Einsatz kommen, wer was tut, wo die Tests laufen, wann sie stattfinden und woran das Team erkennt, dass es fertig ist. Er ist die schriftlich festgehaltene Vereinbarung zwischen QA, Entwicklung und Produkt über das Testen, bevor die Durchführung beginnt. Der Standard IEEE 829 (inzwischen abgelöst durch ISO/IEC/IEEE 29119-3) ist die klassische Vorlage.
Was ein nützlicher Testplan enthält
- Umfang: Features im Umfang und, genauso wichtig, ausdrücklich nicht im Umfang.
- Vorgehen: Teststufen und Testarten (Unit, API, UI, Performance, Sicherheit, Barrierefreiheit), was automatisiert und was manuell getestet wird.
- Umgebungen und Daten: welche Umgebungen, wie Testdaten erzeugt oder maskiert werden, Sandboxes von Drittanbietern.
- Eingangskriterien: was erfüllt sein muss, bevor das Testen beginnt, etwa „Build auf Staging deployt und Smoke-Tests grün“.
- Endekriterien: was „fertig“ bedeutet, etwa „keine offenen kritischen oder schweren Fehler, alle P1-Szenarien bestanden, Regressionssuite grün“.
- Risiken und Gegenmaßnahmen: zum Beispiel „Die Payment-Sandbox ist instabil, daher stubben wir sie für funktionale Tests und führen täglich einen End-to-End-Check gegen die echte Sandbox aus“.
- Rollen, Zeitplan und Ergebnisse: wer was testet, wichtige Termine und welche Berichte erstellt werden.
Testplan vs. Teststrategie
Eine Teststrategie ist das übergeordnete, langlebigere Vorgehen für ein Produkt oder eine Organisation: die Testprinzipien, Teststufen, Tools und Standards. Ein Testplan wendet diese Strategie auf ein Release oder Projekt an, mit konkretem Umfang, Terminen und Personen. Viele agile Teams pflegen eine schlanke Strategieseite und einen kurzen Plan pro Release oder Epic.
Häufige Fehler
- Ein 40-seitiges Dokument schreiben, das niemand liest. In agilen Teams schlägt ein aktuell gehaltener einseitiger Plan einen erschöpfenden, der ab dem zweiten Sprint veraltet ist.
- Vage Endekriterien. „Testen abgeschlossen“ ist nicht messbar. Nennen Sie die Bedingungen.
- Kein Abschnitt zu Ausschlüssen. Nicht ausgesprochene Ausschlüsse werden nach dem Release zum Streitpunkt.