Testkonzept — Grundgerüst
1. Testziele und Umfang
- Ziel: [z. B. Nachweis aller Muss-Anforderungen vor Go-live]
- Im Umfang: [ … ]
- Nicht im Umfang: [ … ]
3. Abnahmekriterien
Vor Testbeginn vereinbaren.
- Alle Muss-Testfälle bestanden
- Keine abnahmehindernden oder schweren Mängel offen
- Leichte Mängel mit Behebungsplan
2. Teststufen
| Stufe | Verantwortlich | Umgebung | Zeitraum |
|---|---|---|---|
| Systemtest | [Lieferant] | [TEST] | [von–bis] |
| Abnahmetest | [Fachbereich] | [ABN] | [von–bis] |
4. Testfälle
| ID | Anforderung | Schritte | Erwartetes Ergebnis | Status |
|---|---|---|---|---|
| T-001 | [A-012] | [ … ] | [ … ] | offen |
Ausdrücke in eckigen Klammern sind Platzhalter. Die Vorlage ist bewusst als Text gehalten, damit sie sich in jedes Werkzeug einfügen lässt — Word, Confluence, Notion oder ein Projektwerkzeug.
Ein Testkonzept legt fest, was mit welchem Ziel, auf welchen Teststufen, in welcher Umgebung, von wem und nach welchen Kriterien getestet wird. Kernstück sind die Abnahmekriterien: Sie definieren vorab, ab wann eine Lösung produktiv gehen darf. Testfälle werden aus den Anforderungen abgeleitet, damit jede Anforderung nachweisbar geprüft ist.
Wofür ein Testkonzept gebraucht wird
Das Testkonzept beantwortet vorab die Fragen, die sonst kurz vor dem Go-live hektisch diskutiert werden: Was muss funktionieren? Wer prüft das? Wie gehen wir mit Fehlern um? Und wann ist es gut genug? Es verbindet die Anforderungen aus Lasten- und Pflichtenheft mit der Abnahme und macht Qualität damit planbar und nachweisbar.
Die Teststufen
| Stufe | Prüft | Typisch verantwortlich |
|---|---|---|
| Komponententest | Einzelne Bausteine isoliert | Entwicklung |
| Integrationstest | Zusammenspiel der Bausteine und Schnittstellen | Entwicklung / Integration |
| Systemtest | Gesamtlösung gegen die Anforderungen | Testteam des Lieferanten |
| Abnahmetest | Eignung aus Sicht der Nutzenden und des Betriebs | Auftraggeber, Fachbereich |
Nicht jedes Projekt braucht jede Stufe in voller Tiefe. Bei der Beschaffung einer Standardlösung liegen Komponenten- und Integrationstests weitgehend beim Hersteller; der Auftraggeber konzentriert sich auf Konfiguration, Schnittstellen und den Abnahmetest.
Testfälle aus Anforderungen ableiten
Jede Muss-Anforderung braucht mindestens einen Testfall, der ihre Erfüllung nachweist. Wird diese Zuordnung konsequent geführt — etwa über die Anforderungsnummer im Testfall —, lässt sich am Ende zeigen, dass alle Anforderungen geprüft wurden. Ein guter Testfall beschreibt Vorbedingung, Schritte, erwartetes Ergebnis und die geprüfte Anforderung.
Nicht-funktionale Anforderungen wie Performance, Sicherheit, Barrierefreiheit oder Datenexport werden gern übersehen, weil sie sich schwerer testen lassen. Gerade sie verursachen im Betrieb die teuersten Probleme.
Abnahmekriterien vorab festlegen
Das wichtigste Kapitel ist das kürzeste: die Abnahmekriterien. Typisch sind Formulierungen wie «alle Muss-Testfälle bestanden, keine abnahmehindernden oder schweren Mängel offen, leichte Mängel mit Behebungsplan». Sie müssen vor Testbeginn vereinbart sein. Wer sie erst während der Tests aushandelt, macht aus jeder Mängelbesprechung eine Grundsatzdiskussion.
Testdaten und Datenschutz
Realistische Tests brauchen realistische Daten. Werden dafür produktive Personendaten verwendet, braucht es eine geklärte Rechtsgrundlage und angemessene Schutzmassnahmen. In vielen Fällen sind anonymisierte oder synthetische Testdaten die bessere Wahl. Das Testkonzept sollte festhalten, welche Daten wo verwendet werden.
Testkonzept in agilen Projekten
In agilen Vorhaben wird kontinuierlich getestet: automatisierte Tests in jeder Iteration, eine Definition of Done pro Backlog-Eintrag, Reviews mit dem Fachbereich. Ein schlankes Testkonzept bleibt trotzdem nützlich — für die übergreifenden Themen: Integrations- und Abnahmetests auf Release-Ebene, Testumgebungen, nicht-funktionale Tests und die Kriterien für den Go-live.
Schlank für kleine Projekte
Für kleine Vorhaben genügt oft eine Seite: Ziele, Umfang, wer testet, eine Liste der wichtigsten Testfälle und klare Abnahmekriterien. Die Vorlage unten lässt sich entsprechend kürzen, ohne die entscheidenden Fragen auszulassen.
Testkonzept
Übernehmen Sie die Struktur nach Word, Confluence oder Ihr Projektwerkzeug. Streichen Sie, was Sie nicht brauchen — eine Vorlage, die unverändert übernommen wird, erzeugt Felder, die niemand füllt und die spätestens beim zweiten Projekt leer bleiben.
- 01
Testziele
Was soll der Test nachweisen? Bezug zu Anforderungen und Risiken.
- 02
Testumfang
Was wird getestet, was ausdrücklich nicht?
- 03
Teststufen
Komponenten-, Integrations-, System-, Abnahmetest — welche und in welcher Tiefe?
- 04
Testumgebung und Testdaten
Wo wird getestet, mit welchen Daten? Umgang mit Personendaten.
Produktive Personendaten nur mit geklärter Rechtsgrundlage.
- 05
Rollen
Wer testet, wer koordiniert, wer entscheidet über die Abnahme?
- 06
Mängelmanagement
Erfassung, Klassierung, Behebung, Nachtest.
- 07
Abnahmekriterien
Ab wann gilt die Lösung als abnahmefähig — z. B. keine abnahmehindernden Mängel, alle Muss-Testfälle bestanden.
Häufige Fragen
- Was gehört in ein Testkonzept?
- Testziele, Testumfang, Teststufen, Testumgebung und Testdaten, Rollen, Mängelmanagement und Abnahmekriterien.
- Wer erstellt das Testkonzept?
- Meist der Lieferant oder das Testteam in Abstimmung mit dem Auftraggeber. Die Abnahmekriterien müssen vom Auftraggeber mitgetragen werden.
- Braucht ein agiles Projekt ein Testkonzept?
- Ein schlankes ja — für Release-Tests, nicht-funktionale Tests, Umgebungen und die Kriterien für den Go-live.