Ein Testkonzept ist das zentrale Steuerungs-Dokument im Software-Test. Es beschreibt, was getestet wird, mit welcher Strategie und mit welchen Ressourcen. Ohne Testkonzept arbeiten Tester reaktiv und Stakeholder verlieren die Übersicht. Mit einem schlanken, gepflegten Testkonzept hast du Skalierbarkeit, Compliance und Audit-Sicherheit in einem.
Dieser Praxis-Guide zeigt dir den Unterschied zwischen Testkonzept, Testplan und Testdrehbuch, die 20-Punkte-Gliederung nach IEEE-829-2008, eine pragmatische Vorlage zum Start und ein konkretes Praxis-Beispiel für ein Web-Projekt. Außerdem erfährst du, wie ein agiles Testkonzept als lebendes Dokument funktioniert.
Für die Rolle des Testmanagers, der das Testkonzept verantwortet, springt der Cluster zu Was macht ein Testmanager?. Für agile Kontexte zum Schwester-Artikel Agiles Testmanagement & Rolle des Testers.
Inhaltsverzeichnis
- Was ist ein Testkonzept?
- Testkonzept vs. Testplan vs. Testdrehbuch
- Inhalte nach IEEE-829-2008 (20-Punkte-Gliederung)
- Testkonzept nach ISTQB
- Vorlage: Aufbau eines Testkonzepts
- Praxis-Beispiel: Testkonzept für ein Web-Projekt
- Agiles Testkonzept als lebendes Dokument
- Häufige Fehler beim Testkonzept-Schreiben
- Fazit
- FAQ
Was ist ein Testkonzept?
Ein Testkonzept ist nach ISTQB-Glossar ein Dokument, das den Gültigkeitsbereich, die Vorgehensweise, die Ressourcen und den Zeitplan der beabsichtigten Tests beschreibt. Es identifiziert Test-Objekte, zu testende Features, Test-Aufgaben und die Personen, die jede Aufgabe übernehmen.
In der Praxis ist das Testkonzept das Master-Dokument, aus dem alle weiteren Test-Artefakte abgeleitet werden: Testfälle, Test-Automatisierungs-Suiten, Defect-Workflows, Test-Reports. Wer ohne Testkonzept startet, sammelt zwar Test-Cases, aber ohne strategischen Rahmen.
Verantwortlich ist der Testmanager. Er schreibt das Konzept zu Projektstart, lässt es im Test-Team gegenlesen und holt sich die Freigabe von Projektleitung, Product Owner und ggf. Compliance. Mehr Praxis-Regeln im Testmanagement-Guide 2026.
Testkonzept vs. Testplan vs. Testdrehbuch
Drei Begriffe, die oft synonym verwendet werden, obwohl sie unterschiedliche Artefakte bezeichnen.
| Artefakt | Was es beschreibt | Wann es entsteht | Wer es nutzt |
|---|---|---|---|
| Testkonzept | Strategie + Scope + Ressourcen + Risiken | Zu Projektstart, dann lebend | Testmanager, Stakeholder, Audit |
| Testplan | Konkrete Zeitplanung + Reihenfolge der Test-Aktivitäten | Aus Testkonzept abgeleitet, pro Test-Stufe | Test-Team, Test-Lead |
| Testdrehbuch (Test-Suite) | Konkrete Testfälle mit Schritten und Erwartungen | Pro Sprint oder Release | Tester (manuell + Automatisierung) |
Praxis-Faustregel: Ein Testkonzept pro Projekt oder Produkt. Ein Testplan pro Test-Stufe (Komponente, Integration, System, Abnahme). Ein Testdrehbuch pro Story oder Feature. In agilen Teams verschmelzen Plan und Drehbuch häufig zu einem ausführbaren Specification-by-Example-Dokument.
Inhalte nach IEEE-829-2008 (20-Punkte-Gliederung)
Der Standard IEEE-829-2008 definiert die kanonische Gliederung für ein Test-Konzept (englisch: Master Test Plan). Auch wenn der Standard 2008 zuletzt aktualisiert wurde, bildet er bis 2026 die Referenz für ISTQB und für Audits in regulierten Branchen.
- Testkonzept-Identifikation: Eindeutige ID, Versionierung
- Einführung: Zweck, Hintergrund, Geltungsbereich
- Referenz-Dokumente: Anforderungen, Architektur, vorgelagerte Test-Konzepte
- Test-Objekt: Was wird getestet (Komponenten, Schnittstellen, Systeme)
- Zu testende Features: Funktionale + nicht-funktionale Anforderungen
- Nicht zu testende Features: Explizite Abgrenzung (Out-of-Scope)
- Vorgehensweise (Approach): Test-Stufen, Test-Arten, Test-Designtechniken
- Akzeptanzkriterien: Wann ist Testen erfolgreich abgeschlossen
- Aussetzungs- und Wiederaufnahmekriterien: Wann pausieren wir, wann weiter
- Test-Lieferobjekte: Test-Plan, Test-Reports, Defect-Listen
- Test-Aufgaben: Aktivitäten mit Reihenfolge und Abhängigkeiten
- Test-Umgebung: Hardware, Software, Daten, Tools
- Verantwortlichkeiten: Wer ist für was zuständig (RACI-Matrix)
- Personalbedarf und Training: Skills, Schulungsbedarf
- Zeitplan: Meilensteine, Deadlines
- Risiken und Eventualfälle: Was könnte schiefgehen, Gegenmaßnahmen
- Genehmigungen: Wer freigibt
- Glossar: Begriffsdefinitionen
- Abnahme der Vorgaben: Sign-off-Prozess
- Anhänge: Detail-Dokumente, Tool-Konfigurationen, Daten-Sets
In der Praxis schreibst du nicht alle 20 Punkte aus. Ein schlankes Testkonzept beschränkt sich auf 8-12 Pflicht-Punkte (siehe Vorlage weiter unten). Die restlichen Punkte sind optional und kommen bei Audit-Anforderungen oder Compliance-Drift dazu.
Testkonzept nach ISTQB
Der ISTQB Foundation Level Syllabus 2018 (aktualisiert 2023) behandelt das Testkonzept im Kapitel „Testmanagement". Wichtigste Punkte:
- Das Testkonzept ist Teil der Testplanungs-Aktivität
- Es identifiziert Test-Strategie, Test-Stufen, Test-Arten, Test-Design
- Risiko-basiertes Testen ist die empfohlene Default-Strategie
- Test-Konzept und Test-Plan werden iterativ verfeinert
- Im agilen Kontext ist das Testkonzept ein Lebendes Dokument, nicht statisch
Auf Advanced Level (CTAL-TM) wird das Testkonzept tiefer behandelt. Der Testmanager lernt, das Konzept an Projekt-Risiko, Team-Größe und Compliance-Anforderungen anzupassen. Wer eine CTAL-TM-Zertifizierung anstrebt, findet die Karriere-Stufen im Testmanager-Karrierepfad.
Vorlage: Aufbau eines Testkonzepts
Eine schlanke 8-Kapitel-Vorlage funktioniert für 80 % aller Projekte. Sie deckt die IEEE-829-Pflichtpunkte ab und ist in 1-2 Tagen schreibbar.
- Einführung und Zielsetzung: Was soll das Testkonzept erreichen, in welchem Projekt-Kontext
- Test-Strategie: Welche Test-Stufen (Komponente, Integration, System, Abnahme), welche Test-Arten (funktional, Performance, Security)
- Test-Scope: Was wird getestet (in-Scope), was nicht (out-of-Scope)
- Test-Designtechniken: Äquivalenzklassen, Grenzwertanalyse, Entscheidungstabellen, Use-Case-Test, Exploratives Testen
- Test-Umgebung und -Tools: Welche Test-Daten, welche Tools (TestRail/Xray/Zephyr, Vergleich im Tools-Hub)
- Test-Phasen und Zeitplan: Welche Test-Stufe wann, mit welchen Akzeptanzkriterien
- Rollen und Verantwortlichkeiten: Testmanager, Test-Lead, Tester, Test-Automation-Engineer
- Risiken und Annahmen: Was könnte das Testen blockieren, welche Annahmen treffen wir
Format-Empfehlung: Confluence-Seite oder Markdown im Repo, nicht Word-Datei. Versionierung über Git oder Confluence-History. So bleibt das Konzept lebend und versionierbar.
Praxis-Beispiel: Testkonzept für ein Web-Projekt
Beispiel aus einem E-Commerce-Projekt: Online-Shop mit 50.000 Bestellungen pro Tag, Migration von Legacy-Shop zu modernem Stack.
| Kapitel | Inhalt |
|---|---|
| Zielsetzung | Funktionale Korrektheit + Performance unter 500 Concurrent Users + Migrations-Datenintegrität |
| Test-Strategie | 4 Stufen: Unit (Entwickler), Komponenten (Tester), Integration (Tester + Architekt), Abnahme (Product Owner) |
| In-Scope | Bestellprozess, Warenkorb, Suche, Migrations-Daten-Konsistenz, Performance, Accessibility WCAG 2.1 AA |
| Out-of-Scope | Legacy-Backoffice (wird ersetzt, separates Testkonzept), CMS-Inhalte |
| Test-Designtechniken | Äquivalenzklassen für Eingabefelder, Use-Case-Tests für Bestellprozess, Exploratives Testen für Such-Algorithmus |
| Tools | Xray for Jira (TM), Playwright (E2E), k6 (Performance), Postman (API) |
| Zeitplan | Sprint 1-4 Unit + Komponenten, Sprint 5-8 Integration, Sprint 9-10 Abnahme + Migration |
| Rollen | Testmanager (1), Test-Lead (1), Tester (3), Performance-Tester (1), Test-Architekt (extern) |
| Risiken | Migrations-Datenfehler (hoch), Performance unter Last (mittel), Browser-Kompatibilität (niedrig) |
Dieses schlanke Konzept passt auf 6-8 Confluence-Seiten und wird pro Sprint im Backlog Refinement angepasst. Anhang: detaillierte Test-Daten-Sets, Tool-Konfigurationen, RACI-Matrix.
Agiles Testkonzept als lebendes Dokument
Im klassischen Wasserfall ist das Testkonzept ein statisches Dokument, das einmal zu Projektstart geschrieben wird. Im agilen Umfeld funktioniert das nicht: Anforderungen ändern sich pro Sprint, Test-Strategie muss sich mitbewegen.
Praxis-Pattern für agile Testkonzepte:
- Confluence-Seite oder Markdown-Datei mit aktiver Versionierung
- Pro Sprint im Backlog Refinement geprüft und angepasst
- Akzeptanzkriterien als ausführbare Specification by Example (Gherkin)
- Test-Strategie pro Quartal im Team-Retro überprüft
- Tool-Stack-Änderungen werden im Konzept dokumentiert, nicht in separaten Mails
Wichtig: Auch agile Teams brauchen ein Testkonzept. Wer ohne Konzept arbeitet, hat keine Cluster-Übersicht und kein Audit-Material. Mehr zum Whole-Team-Ansatz im Agiles Testmanagement-Guide oder zur Einbettung in Scrum/Kanban/SAFe im Framework-Pillar.
Häufige Fehler beim Testkonzept-Schreiben
- 20-Punkte-Marathon: Wer alle IEEE-829-Punkte zwanghaft befüllt, schreibt 50 Seiten, die niemand liest. Schlank starten mit 8 Pflicht-Kapiteln, optional erweitern.
- Statisch und tot: Ein Testkonzept als PDF im Archiv ist Karteileiche. Pflegen als Living Document in Confluence oder Markdown.
- Tool-Auswahl im Konzept treffen: Tools gehören in einen Anhang oder eine Tool-Strategie, nicht in die Hauptkapitel. Sonst wird das Konzept beim Tool-Wechsel obsolet.
- Out-of-Scope nicht definieren: Wer nur das In-Scope listet, lädt Scope-Creep ein. Explizite Out-of-Scope-Liste schützt vor späteren Streitigkeiten.
- RACI-Matrix vergessen: Wenn nicht klar ist, wer freigibt und wer informiert wird, gibt es Defect-Eskalations-Streits.
- Risiken oberflächlich: „Risiko: Performance-Probleme" ist kein Risiko-Eintrag. Konkret werden: Welche Wahrscheinlichkeit, welche Auswirkung, welche Gegenmaßnahme.
- Akzeptanzkriterien unscharf: „Akzeptable Test-Coverage" reicht nicht. Konkrete Schwelle (z.B. „90 % Branch Coverage für Kernmodule, 70 % für UI-Komponenten").
Fazit
Ein Testkonzept ist 2026 unverzichtbar, egal ob klassisch oder agil. Es bringt Test-Strategie auf den Punkt, definiert Rollen und Akzeptanzkriterien und schützt vor Scope-Creep. IEEE-829-2008 ist die Referenz für die Gliederung, ISTQB für die Methodik.
Wer ein Testkonzept neu schreibt, startet mit der 8-Kapitel-Vorlage aus diesem Guide und erweitert nur bei Audit-Bedarf. Wer ein bestehendes Konzept refresht, prüft zuerst die Out-of-Scope-Liste und die RACI-Matrix. Mehr Praxis-Regeln zur Pflege im Testmanagement-Guide 2026 oder zur Tool-Wahl im Testmanagement-Tools-Hub.
FAQ
Was gehört in ein Testkonzept?
Acht Pflicht-Kapitel: Einführung, Test-Strategie, Test-Scope, Test-Designtechniken, Test-Umgebung und Tools, Test-Phasen und Zeitplan, Rollen und Verantwortlichkeiten, Risiken und Annahmen. Optional erweiterbar nach IEEE-829-2008 mit RACI-Matrix, Akzeptanzkriterien, Aussetzungs-Kriterien und Genehmigungen.
Was ist der Unterschied zwischen Testkonzept und Testplan?
Das Testkonzept beschreibt Strategie, Scope und Ressourcen für ein Projekt oder Produkt. Der Testplan ist die konkrete Zeitplanung pro Test-Stufe (Komponente, Integration, System, Abnahme), abgeleitet aus dem Testkonzept. Ein Testkonzept pro Projekt, mehrere Testpläne pro Konzept.
Wie lang sollte ein Testkonzept sein?
Schlank starten: 6-10 Seiten oder Confluence-Pages decken 80 % der Projekte ab. Audit-pflichtige Branchen (Pharma, Banking, Medizintechnik) brauchen oft 20-50 Seiten mit allen IEEE-829-Punkten. Lieber kurz und gepflegt als lang und tot.
Welche Vorlage nutzt man für ein Testkonzept?
Die IEEE-829-2008-Gliederung ist Industrie-Standard. Pragmatisch reicht die 8-Kapitel-Vorlage aus diesem Artikel. Format: Confluence oder Markdown im Repo, nicht Word-Datei. Mit Versionierung über Git oder Confluence-History.
Wer schreibt das Testkonzept?
Der Testmanager ist verantwortlich. In agilen Teams ohne dedizierte Testmanager-Rolle übernimmt das der Test-Lead oder ein Quality Architect. Wichtig: Gegenlesen durch Test-Team, Product Owner und ggf. Compliance.
Wie unterscheidet sich ein agiles Testkonzept vom klassischen?
Klassisch: statisches Dokument zu Projektstart. Agil: Lebendes Dokument, pro Sprint angepasst. Akzeptanzkriterien als Gherkin-Specification by Example. Test-Strategie pro Quartal im Team-Retro überprüft. Mehr im Agile-Testmanagement-Guide.
Was ist eine RACI-Matrix im Testkonzept?
RACI steht für Responsible (verantwortlich), Accountable (rechenschaftspflichtig), Consulted (befragt), Informed (informiert). Die Matrix legt pro Test-Aufgabe fest, wer welche Rolle hat. Sie verhindert Defect-Eskalations-Streits und Audit-Lücken.