Ein Testplan klingt nach Bürokratie – bis ein Audit ihn verlangt oder ein Release ohne klare Kriterien scheitert. Genau dann zeigt sich, ob das Dokument trägt. Ein guter Plan beschreibt nicht jeden Klick, sondern macht Umfang, Vorgehen, Ressourcen und Zeitplan einer Teststufe nachvollziehbar. Für QA-Leads und Testmanager im DACH-Raum ist das mehr als Formalie: In regulierten Branchen ist er das Rückgrat der Audit-Readiness. Dieser Artikel zeigt, was er nach aktuellem Standard enthalten muss, wie er sich von Teststrategie und Testkonzept abgrenzt – und wie er in agilen wie regulierten Teams schlank bleibt.

Kurz gefasst: Ein Testplan beschreibt laut ISTQB Umfang, Vorgehen, Ressourcen und Zeitplan geplanter Testaktivitäten (ISTQB Glossary, 2024). Maßgeblich ist heute ISO/IEC/IEEE 29119-3 – IEEE 829 ist formal abgelöst (IEEE SA, 2008). Der Standard definiert rund 13 Inhaltsabschnitte, von Risikoregister bis Ein-/Austrittskriterien. In regulierten Branchen ist dieser dokumentierte, wiederholbare Plan die Basis jedes Audits.

Abbildung 1: Die vier Kernelemente eines Testplans nach ISTQB-Definition.

Was ist ein Testplan?

Ein Testplan ist laut ISTQB ein Dokument, das Umfang, Vorgehen, Ressourcen und Zeitplan der geplanten Testaktivitäten beschreibt (ISTQB Glossary, 2024). Er identifiziert die Testobjekte, die zu testenden Merkmale, die Testaufgaben und die Verantwortlichen – also wer was tut.

Konkret hält der Plan auch fest, welche Tester unabhängig arbeiten, welche Testumgebung nötig ist und welche Testentwurfsverfahren zum Einsatz kommen. Hinzu kommen Ein- und Austrittskriterien sowie die Risiken, die eine Notfallplanung erfordern. Der Plan ist damit weniger eine Anleitung als eine Vereinbarung darüber, was getestet wird und wann der Test als beendet gilt.

Wichtig ist die Reichweite. Ein solcher Plan bezieht sich in der Regel auf ein Projekt oder eine konkrete Teststufe. Er beantwortet nicht die Frage, wie eine ganze Organisation testet – das ist Aufgabe der Teststrategie. Diese Abgrenzung sorgt regelmäßig für Verwirrung, deshalb klären wir sie direkt im nächsten Abschnitt.

Testplan vs. Teststrategie vs. Testkonzept – was ist der Unterschied?

Abbildung 2: Reichweite und Zeithorizont von Teststrategie, Testkonzept und Testplan im Vergleich.

Die drei Begriffe werden oft synonym verwendet, meinen aber unterschiedliche Dinge. Laut ISTQB ist eine Teststrategie eine übergreifende Beschreibung der Teststufen für eine Organisation oder ein Programm aus einem oder mehreren Projekten (ISTQB Glossary, 2024). Die Strategie wirkt also organisationsweit, der Testplan dagegen projekt- oder teststufenbezogen.

Beim Testkonzept lohnt ein genauer Blick. Im deutschen ISTQB-Glossar ist »Testkonzept« schlicht die Übersetzung von »test plan« – beide tragen dieselbe Definition (ISTQB Glossary DE, 2024). Die in vielen deutschen Teams verbreitete Hierarchie »Testkonzept = Master, Testplan = pro Teststufe« ist also Praxiskonvention, nicht ISTQB-Definition. Wer das offenlegt, vermeidet Missverständnisse im Audit.

Quelle: ISTQB Glossary und Teststrategie (2024).

Praxisnotiz: In Kundenprojekten erleben wir regelmäßig, dass »Testkonzept« und »Testplan« vermischt werden. Solange das Team eine eigene Begriffsdefinition dokumentiert, ist das kein Problem – ein Audit fragt nach Konsistenz, nicht nach reiner Lehre.

Mehr zu den verschiedenen Prüfebenen finden Sie in unserem Überblick zu Software-Testarten.

Welcher Standard gilt heute?

Maßgeblich ist heute die Normenreihe ISO/IEC/IEEE 29119. Der ältere IEEE 829-2008 ist formal durch ISO/IEC/IEEE 29119-1, -2, -3 und -4 abgelöst (IEEE SA, 2008). Wer einen Testplan heute an IEEE 829 ausrichtet, arbeitet also an einem überholten Dokument vorbei – ein vermeidbarer Befund im Audit.

Den konkreten Aufbau der Testdokumentation regelt ISO/IEC/IEEE 29119-3 (aktuelle Ausgabe 2021). Die Norm definiert Vorlagen für Testdokumente als Ergebnisse der Prozesse aus 29119-2 (IEEE SA, 2021; ISO, 2021). Sie schreibt keine starre Form vor, sondern liefert ein Gerüst, das Teams an ihren Kontext anpassen.

Der praktische Vorteil ist Vergleichbarkeit. Ein nach 29119-3 strukturierter Plan ist für Prüfer wiedererkennbar, weil er den international gültigen Abschnitten folgt. Das beschleunigt jedes Audit und reduziert Rückfragen. Im nächsten Abschnitt sehen Sie, welche Abschnitte das konkret sind.

Aufbau und Inhalt eines Testplans

Abbildung 3: Die 13 kanonischen Abschnitte eines Testplans nach ISO/IEC/IEEE 29119-3.

Ein Testplan nach ISO/IEC/IEEE 29119-3 deckt rund 13 inhaltliche Bausteine ab – vom Kontext des Testens über das Risikoregister bis zu Abschlusskriterien und Zeitplan (microTOOL, 2021). Diese Struktur ist das Gerüst, an dem sich jede Vorlage orientieren sollte. Sie zwingt zur Vollständigkeit, ohne den Inhalt vorzuschreiben.

Die kanonischen Abschnitte eines Testplans nach 29119-3:

• Kontext des Testens: Projekt, Testobjekt(e), Umfang, Annahmen und Einschränkungen, Stakeholder

• Kommunikation: wer wird wie über Teststatus und Ergebnisse informiert

• Risikoregister: Produktrisiken und Projektrisiken mit Bewertung

• Teststrategie / Subprozesse: gewähltes Vorgehen je Teststufe

• Testlieferobjekte: welche Artefakte das Testen produziert

• Testentwurfsverfahren: angewandte Design-Techniken

• Abschlusskriterien: Ein- und Austrittskriterien je Aktivität

• Metriken: wie Fortschritt und Qualität gemessen werden

• Testdaten und Testumgebung: benötigte Daten, Infrastruktur, Tools

• Retest und Regression: Vorgehen nach Fehlerbehebung

• Aussetzung und Wiederaufnahme: wann Tests pausieren und neu starten

• Personal: Rollen, Verantwortlichkeiten, Skills

• Zeitplan: Meilensteine und Termine der Testaktivitäten

Nicht jeder Abschnitt muss in jedem Projekt gleich tief ausfallen. Die Kunst liegt darin, jeden Punkt bewusst zu adressieren – auch wenn die Antwort »nicht relevant, weil …« lautet. Genau diese dokumentierte Entscheidung unterscheidet einen tragfähigen Plan von einer Pflichtübung. Wie Sie die Vollständigkeit der Prüfung messbar machen, zeigt unser Beitrag zur Testabdeckung.

Warum ist der Testplan in regulierten Branchen entscheidend?

Abbildung 4: DORA verlangt mindestens jährliche, dokumentierte Tests kritischer IKT-Systeme.

In regulierten Branchen ist der Plan kein Verwaltungsakt, sondern Audit-Backbone. Unter DORA – Verordnung (EU) 2022/2554 – müssen Finanzunternehmen ihre kritischen IKT-Systeme regelmäßig, mindestens jährlich, testen und Ergebnisse samt Behebungsstatus nachvollziehbar dokumentieren (Regulation (EU) 2022/2554, Art. 24–26). Aufsichtsbehörden wollen belegte Resilienz, keine reine Papier-Compliance.

Genau hier wird ein strukturierter Plan zum Vorteil. Er hält fest, was wann mit welchen Kriterien getestet wurde und wer verantwortlich war. Diese Nachvollziehbarkeit ist die Grundlage jedes manipulationssicheren Prüfpfads. Fehlt der Plan, lässt sich im Audit kaum belegen, dass Tests systematisch und wiederholbar stattgefunden haben.

Reproduzierbarkeit ist dabei der Kern. Ein Plan, der bei jedem Lauf zu denselben definierten Schritten und Kriterien führt, liefert genau die konsistenten Nachweise, die ein Audit verlangt. Automatisierte, dokumentierte Testabläufe verstärken diesen Effekt, weil sie menschliche Variabilität reduzieren. Wie sich solche Abläufe konsistent aufsetzen lassen, zeigen unsere Test-Workflows.

Wie sieht ein schlanker Testplan in agilen Teams aus?

Auch agile Teams brauchen einen solchen Plan – nur in anderer Form. Die 29119-3-Abschnitte gelten weiter, doch der Plan lebt oft als kompaktes, lebendes Dokument statt als 40-Seiten-PDF. Entscheidend ist, dass jeder kanonische Punkt eine bewusste Antwort hat, nicht dass jeder Punkt seitenlang ausgeführt wird.

In der Praxis bewährt sich ein verschlanktes Format. Risikoregister, Ein- und Austrittskriterien sowie Testumgebung gehören fest hinein, weil sie über Releasefähigkeit entscheiden. Detailtiefe bei Personal oder Kommunikation lässt sich dagegen oft auf wenige Zeilen kürzen, wenn das Team klein und eingespielt ist.

Ein häufiger Fehler ist das Gegenteil von Bürokratie: gar kein Plan. Ohne dokumentierte Austrittskriterien entscheidet das Bauchgefühl über das Release – im regulierten Umfeld ein Risiko. Ein schlanker, aber vollständiger Plan löst diesen Zielkonflikt. Wie ein konkretes Quality Gate vor dem Release aussieht, beschreibt unser Leitfaden zum Smoke Test. Den breiteren Kontext liefert unser Überblick zur Testpyramide.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Testplan und Testkonzept?

Im deutschen ISTQB-Glossar gibt es keinen: »Testkonzept« ist die Übersetzung von »test plan« und trägt dieselbe Definition (ISTQB Glossary DE, 2024). Die verbreitete Trennung »Testkonzept = Master, Testplan = pro Teststufe« ist Praxiskonvention. Sie ist zulässig, sollte aber im Dokument selbst definiert werden, um Audit-Rückfragen zu vermeiden.

Welcher Standard gilt für Testpläne – IEEE 829 oder ISO 29119?

Maßgeblich ist ISO/IEC/IEEE 29119, IEEE 829-2008 ist formal abgelöst (IEEE SA, 2008). Den Aufbau der Testdokumentation regelt konkret ISO/IEC/IEEE 29119-3 in der Ausgabe von 2021 (IEEE SA, 2021). Neue Testpläne sollten am aktuellen Standard ausgerichtet werden, nicht am abgelösten IEEE 829.

Welche Abschnitte muss ein Testplan enthalten?

Nach ISO/IEC/IEEE 29119-3 rund 13 Bausteine: Kontext des Testens, Kommunikation, Risikoregister, Teststrategie, Testlieferobjekte, Entwurfsverfahren, Abschlusskriterien, Metriken, Testdaten und -umgebung, Retest und Regression, Aussetzung und Wiederaufnahme, Personal sowie Zeitplan (microTOOL, 2021). Tiefe und Umfang passt das Team an seinen Kontext an.

Braucht ein agiles Team überhaupt einen Testplan?

Ja, nur in schlankerer Form. Die kanonischen Abschnitte bleiben gültig, doch der Plan lebt oft als kompaktes, lebendes Dokument. Wichtig sind vor allem Risikoregister, Ein- und Austrittskriterien sowie Testumgebung, weil sie über die Releasefähigkeit entscheiden. Fehlende dokumentierte Kriterien sind gerade im regulierten Umfeld ein echtes Risiko.

Wie hilft ein Testplan bei der Audit-Readiness unter DORA?

DORA verlangt regelmäßiges, dokumentiertes Testen kritischer IKT-Systeme samt Behebungsstatus (Regulation (EU) 2022/2554, Art. 24–26). Ein strukturierter, wiederholbarer Plan liefert genau die nachvollziehbaren Nachweise, die Aufsichtsbehörden erwarten. Er belegt, was wann mit welchen Kriterien getestet wurde – die Grundlage eines manipulationssicheren Prüfpfads.

Fazit

Ein Testplan ist kein Selbstzweck, sondern die Vereinbarung darüber, was getestet wird und wann ein Test als beendet gilt. Maßgeblich ist heute ISO/IEC/IEEE 29119-3, nicht das abgelöste IEEE 829 (IEEE SA, 2008). Wer die rund 13 Abschnitte bewusst adressiert – vom Risikoregister bis zu den Austrittskriterien – erhält ein Dokument, das in agilen wie regulierten Teams trägt. Im DACH-Banking unter DORA wird dieser dokumentierte, wiederholbare Plan zum Rückgrat jeder Audit-Readiness. Entscheidend ist nicht der Umfang, sondern die Vollständigkeit und die Reproduzierbarkeit der Testabläufe. Möchten Sie Ihre Testabläufe so aufsetzen, dass jeder Lauf audit-fest dokumentiert ist? Sprechen Sie mit unserem Team.