← Zurück zu Insights Qualitätssicherung · Testmanagement

Testkonzept erstellen: Aufbau, Inhalte und Vorgehen in der Praxis

23. Oktober 2026 · Ramin Amini

„Wir testen am Ende, wenn alles fertig ist“ – dieser Satz steht am Anfang vieler schwieriger Go-lives. Ohne Testkonzept ist unklar, was getestet wird, wer testet, auf welcher Umgebung und wann eine Software als ausreichend geprüft gilt. Die Folge sind Diskussionen kurz vor dem Release, fehlende Testdaten und eine Freigabe nach Bauchgefühl. Ein gutes Testkonzept beantwortet diese Fragen, bevor sie zum Problem werden. Dieser Artikel zeigt, welche Inhalte hineingehören, wie Sie ein Testkonzept Schritt für Schritt erstellen und wie es auch in agilen Projekten schlank bleibt.

Was ist ein Testkonzept?

Ein Testkonzept beschreibt, wie in einem konkreten Projekt oder Release getestet wird: Ziele, Umfang, Vorgehen, Ressourcen, Zeitplan und die Kriterien, nach denen über die Freigabe entschieden wird. Im ISTQB-Vokabular entspricht es dem Testplan; als Orientierung für Aufbau und Inhalte dient häufig die Norm ISO/IEC/IEEE 29119-3, die den früheren Standard IEEE 829 abgelöst hat.

Wichtig ist die Abgrenzung zu zwei verwandten Begriffen:

• Teststrategie: Sie legt übergreifend fest, wie eine Organisation oder ein Programm grundsätzlich testet – etwa welche Teststufen Standard sind oder welcher Automatisierungsgrad angestrebt wird. Das Testkonzept setzt diese Vorgaben für ein konkretes Projekt um.
• Testfälle: Sie beschreiben einzelne Prüfungen mit Vorbedingungen, Schritten und erwartetem Ergebnis. Das Testkonzept definiert den Rahmen, aus dem die Testfälle später abgeleitet werden.

Wann lohnt sich ein Testkonzept – und wie umfangreich sollte es sein?

Ein Testkonzept lohnt sich immer dann, wenn mehrere Beteiligte zusammenarbeiten: Entwicklung, Fachbereich, Betrieb, externe Dienstleister. Spätestens bei Schnittstellen zu anderen Systemen, regulatorischen Anforderungen oder einer formalen Abnahme ist es unverzichtbar. Der Umfang richtet sich nach dem Risiko, nicht nach einer Vorlage. Für eine überschaubare Anwendung genügen oft wenige Seiten; bei einer Kernsystem-Migration mit vielen Schnittstellen darf es deutlich detaillierter sein. Entscheidend ist, dass das Dokument gelesen und genutzt wird – ein 60-seitiges Konzept, das niemand kennt, hilft nicht.

Aufbau: Diese Inhalte gehören in ein Testkonzept

1. Ziele, Testobjekte und Abgrenzung

Was soll der Test nachweisen, und was wird getestet? Hier werden Systeme, Module, Schnittstellen und Release-Umfang benannt. Ebenso wichtig ist, was ausdrücklich nicht getestet wird – etwa Fremdsysteme, die der Lieferant verantwortet. Eine klare Abgrenzung verhindert spätere Missverständnisse über Zuständigkeiten.

2. Teststufen und Testarten

Welche Teststufen gibt es im Projekt – Komponententest, Integrationstest, Systemtest, Abnahmetest – und wer ist jeweils verantwortlich? Dazu kommen die Testarten: funktionale Tests, Regressionstests und nicht-funktionale Tests wie Performance, Sicherheit oder Usability. Für die letzte Stufe vor dem Go-live lohnt ein Blick in unseren Artikel Abnahmetests: So gelingt die Softwareabnahme sicher.

3. Risikobasierte Priorisierung

Nicht alles lässt sich gleich gründlich testen. Ein gutes Testkonzept bewertet die Funktionen nach Geschäftskritikalität und Fehlerwahrscheinlichkeit und leitet daraus die Testtiefe ab. Kritische Kernprozesse werden intensiv geprüft, Randfunktionen mit geringerem Aufwand. Die Projektrisiken aus dem Risikomanagement in IT-Projekten sind dafür eine wertvolle Quelle.

4. Testumgebung und Testdaten

Auf welchen Umgebungen wird getestet, wer stellt sie bereit, und wie nah sind sie an der Produktion? Testdaten sind ein häufig unterschätzter Engpass: Werden anonymisierte Produktionsdaten verwendet oder synthetische Daten erzeugt? Bei personenbezogenen Daten muss der Datenschutz von Anfang an mitgedacht werden.

5. Rollen, Verantwortlichkeiten und Zeitplan

Wer erstellt Testfälle, wer führt sie aus, wer bewertet Fehler und wer gibt frei? Ein Zeitplan mit Testphasen und Meilensteinen gehört ebenso dazu wie die Abstimmung mit dem Projektplan. Besonders wichtig: Die Verfügbarkeit des Fachbereichs für Tests und Abnahme muss früh eingeplant werden.

6. Eingangs-, Ende- und Abbruchkriterien

Wann kann eine Testphase beginnen (etwa: Build installiert, Smoke-Test bestanden, Testdaten vorhanden)? Wann ist sie abgeschlossen (etwa: alle priorisierten Testfälle durchgeführt, keine offenen kritischen Fehler)? Und wann wird sie unterbrochen, weil ein sinnvolles Testen nicht möglich ist? Messbare Kriterien machen die Freigabeentscheidung nachvollziehbar.

7. Fehlermanagement und Reporting

Wie werden Fehler erfasst, klassifiziert und nachverfolgt? Welche Schweregrade gibt es, und wer entscheidet über deren Behebung? Dazu kommt das Reporting: Welche Kennzahlen – etwa Testfortschritt, offene Fehler nach Schweregrad, Anforderungsabdeckung – werden wann an wen berichtet? Am Ende steht ein Testabschlussbericht mit einer klaren Freigabeempfehlung.

Testkonzept erstellen: Vorgehen in fünf Schritten

• Grundlagen sammeln: Anforderungen, Architektur, Projektplan und Risiken sichten. Unklare Anforderungen sind ein Warnsignal – testbare Anforderungen sind die Basis jedes Tests, wie unser Artikel Der unterschätzte Erfolgsfaktor: saubere Anforderungen zeigt.
• Mit den Beteiligten abstimmen: In einem kurzen Workshop mit Projektleitung, Entwicklung, Fachbereich und Betrieb Umfang, Prioritäten und Verantwortlichkeiten klären.
• Erste Fassung schreiben: Die Gliederung oben als Leitfaden nutzen und jeden Abschnitt so knapp wie möglich, aber so konkret wie nötig füllen.
• Review und Freigabe: Das Konzept von den Beteiligten prüfen lassen und formal freigeben – damit wird es zur verbindlichen Grundlage.
• Lebendig halten: Ändern sich Umfang, Termine oder Risiken, wird das Testkonzept angepasst. Eine Versionshistorie macht Änderungen nachvollziehbar.

Testkonzept in agilen Projekten

Auch in Scrum-Teams braucht es Klarheit über das Testvorgehen – nur in anderer Form. Statt eines umfangreichen Dokuments zu Projektbeginn bewährt sich ein schlankes, übergreifendes Testkonzept, das Teststufen, Umgebungen, Automatisierungsansatz und Qualitätskriterien festlegt. Die Details wandern in die Arbeitsweise des Teams: Akzeptanzkriterien in jeder User Story, Testaspekte in der Definition of Done und Regressionstests, die mit jedem Sprint mitwachsen. Wie Sie diese Regressionstests sinnvoll planen, lesen Sie in Regressionstests: So sichern Sie stabile Releases ab; den Weg zur automatisierten Ausführung beschreibt Testautomatisierung einführen in 6 Schritten.

Typische Fehler beim Testkonzept

• Copy-and-paste aus dem letzten Projekt: Vorlagen sind hilfreich, aber Risiken, Systeme und Beteiligte sind jedes Mal andere.
• Zu spät erstellt: Wird das Testkonzept erst kurz vor der Testphase geschrieben, fehlen Testumgebungen, Testdaten und Kapazitäten, die man hätte rechtzeitig einplanen müssen.
• Keine messbaren Endekriterien: Ohne sie wird die Freigabe zur Verhandlungssache.
• Nicht-funktionale Anforderungen vergessen: Performance, Sicherheit und Betriebsfähigkeit fallen sonst erst in der Produktion auf – etwa ohne rechtzeitige Lasttests.
• Dokument ohne Leser: Ein Testkonzept, das nicht abgestimmt und freigegeben wurde, wird im Projektalltag ignoriert.

Fazit

Ein Testkonzept ist kein Selbstzweck, sondern das gemeinsame Verständnis darüber, wie Qualität im Projekt nachgewiesen wird. Wer Ziele, Umfang, Prioritäten, Umgebungen, Verantwortlichkeiten und Freigabekriterien früh klärt, vermeidet Diskussionen kurz vor dem Go-live und schafft eine belastbare Grundlage für die Release-Entscheidung. Warum Qualitätssicherung insgesamt über den Projekterfolg entscheidet, lesen Sie in Warum Qualitätssicherung über den Projekterfolg entscheidet.

Häufige Fragen zum Testkonzept

Was ist der Unterschied zwischen Testkonzept und Teststrategie?

Die Teststrategie legt übergreifend fest, wie eine Organisation oder ein Programm grundsätzlich testet. Das Testkonzept setzt diese Vorgaben für ein konkretes Projekt oder Release um und beschreibt Umfang, Vorgehen, Ressourcen, Zeitplan und Freigabekriterien.

Wer erstellt das Testkonzept?

In der Regel der Testmanager oder die verantwortliche Person für die Qualitätssicherung. Erarbeitet wird es gemeinsam mit Projektleitung, Entwicklung, Fachbereich und Betrieb, und es wird von den Beteiligten geprüft und freigegeben.

Braucht man in Scrum ein Testkonzept?

Ja, aber in schlanker Form. Ein übergreifendes Testkonzept regelt Teststufen, Umgebungen, Automatisierung und Qualitätskriterien. Die Details stehen in den Akzeptanzkriterien der User Stories und in der Definition of Done.