Was sind Teststufen?
Teststufen beschreiben unterschiedliche Phasen im Testprozess, jede mit einer eigenen Zielsetzung. Sie folgen nicht einfach aufeinander, sondern nehmen jeweils einen anderen Aspekt des Softwaresystems in den Blick: Jede Stufe hat eigene Testziele, eigene Testobjekte, eine eigene Testbasis und einen typischen Kreis von Fehlerzuständen, den sie aufdeckt. Und zwar genau deshalb, weil die Fehler dort entstehen.
Die Grundidee ist pragmatisch: Ein früh gefundener Fehler ist billiger als ein spät entdeckter. Jede Teststufe ist so angelegt, dass sie Fehler auf der Ebene einfängt, auf der sie üblicherweise entstehen. Bugs innerhalb einer Komponente zeigen sich im Komponententest. Probleme zwischen Komponenten werden im Komponenten-Integrationstest sichtbar, während der System-Integrationstest die Schnittstellen zu anderen Systemen und externen Services prüft. Systemfehler und nicht-funktionale Mängel gehören in den Systemtest. Und ob das System am Ende wirklich das leistet, was der Auftraggeber braucht, klärt der Abnahmetest. Die Teststufen ergänzen einander, ohne dass jedes Projekt sie zwingend in einer starren Reihenfolge durchlaufen muss.
Teststufen sind aber auch ein Planungswerkzeug, und in dieser zweiten Funktion werden sie gerne unterschätzt. Wer zu Projektbeginn festlegt, welche Stufen wie bespielt werden, schafft Klarheit über Ressourcen, Verantwortlichkeiten und Testziele, bevor die erste Zeile Code existiert. Die Diskussion über Teststufen zwingt ein Team, vier Fragen auszusprechen: Was wird getestet? Von wem? Auf welcher Grundlage? Zu welchem Zeitpunkt? Genau diese Fragen bleiben sonst offen, bis es unbequem wird, sie zu beantworten.
Die fünf Teststufen
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
Die folgende Einteilung in fünf Stufen hat sich als gemeinsame Landkarte weitgehend durchgesetzt, unter anderem nutzt sie der ISTQB Foundation Level. Verbindlich ist sie nicht: Teams können Stufen zusammenlegen, weglassen oder eigene definieren.
Komponententest
Der Komponententest, auch Unit-Test oder Modultest genannt, prüft einzelne Softwarekomponenten isoliert vom Rest des Systems. Testobjekte sind Klassen, Funktionen, Module oder andere abgrenzbare Einheiten. Die Testbasis bilden Komponentenspezifikationen, Entwurfsmodelle und der Sourcecode selbst. Typische Fehlerzustände dieser Stufe entstehen in der inneren Logik einer Einheit: falsche Algorithmen, unsaubere Grenzwertbehandlung, fehlerhafte Berechnungen, unbehandelte Ausnahmefälle.
Verantwortlich sind in aller Regel die Entwicklerinnen und Entwickler selbst, unterstützt von Testframeworks wie JUnit für Java, pytest für Python oder NUnit für .NET. Damit eine Komponente wirklich isoliert betrachtet werden kann, ersetzen Stub- und Mock-Objekte ihre externen Abhängigkeiten. An dieser Isolation hängt die ganze Aussagekraft: Läuft ein Test nicht isoliert, prüft er immer auch die Abhängigkeiten mit, und dann lässt sich nicht mehr sagen, wo ein Fehler wirklich sitzt. Der Komponententest ist die schnellste und günstigste Stufe. Ein Bug, der hier gefunden wird, kostet nur einen Bruchteil dessen, was er im Systemtest oder gar in Produktion verursacht hätte.
Komponenten-Integrationstest
Der Komponenten-Integrationstest prüft die Schnittstellen und Interaktionen zwischen integrierten Komponenten innerhalb eines Systems. Er betrachtet also genau den Bereich, in dem einzeln funktionierende Bausteine unerwartet aneinander scheitern. Testobjekte sind beispielsweise gemeinsam arbeitende Klassen, Module, Services oder Subsysteme.
Die Testbasis bilden Softwarearchitektur, Komponentenspezifikationen, Schnittstellenbeschreibungen und API-Dokumentationen. Typische Fehlerzustände sind falsch übergebene Daten, fehlerhafte Aufrufsequenzen, inkompatible Datenformate und eine Fehlerbehandlung, die über Komponentengrenzen hinweg nicht mehr greift. Verantwortet wird diese Stufe häufig von der Entwicklung und sie lässt sich gut in Continuous-Integration-Pipelines automatisieren. Bewährt hat sich ein inkrementelles Vorgehen: erst die kleinsten sinnvollen Gruppen integrieren und prüfen, dann den Umfang schrittweise erweitern.
Systemtest
Der Systemtest betrachtet das vollständig integrierte System als Ganzes und prüft es gegen seine spezifizierten Anforderungen. Er ist die umfassendste Stufe innerhalb der softwareentwickelnden Organisation und die letzte, bevor das System die Hände seiner Erbauer verlässt. Die Testbasis umfasst Systemspezifikationen, Anforderungsdokumente, Risikobewertungen und Use Cases. Geprüft werden funktionale und nicht-funktionale Anforderungen gleichermaßen: Performance, Sicherheit, Zuverlässigkeit, Usability und Kompatibilität gehören alle auf diese Ebene.
Systemtests werden häufig von einem Testteam durchgeführt, das teilweise oder vollständig unabhängig von der Entwicklung arbeitet. Ein anderer Blickwinkel kann andere Fehler finden und Annahmen hinterfragen. Der konkrete Unabhängigkeitsgrad ist aber keine Eigenschaft der Teststufe selbst: Er richtet sich nach Risiko, Entwicklungsmodell und Projektkontext; auch Entwicklungsteams können Systemtests durchführen.
System-Integrationstest
Der System-Integrationstest prüft die Schnittstellen und Interaktionen zwischen dem getesteten System und anderen Systemen oder externen Services. Dazu gehören beispielsweise Zahlungsdienste, Identity Provider, Partner-APIs, Hardware-Schnittstellen und gemeinsam genutzte Datenplattformen. Im Unterschied zum Komponenten-Integrationstest liegt der Fokus damit außerhalb der Grenzen des einzelnen Systems.
Als Testbasis dienen Systemarchitektur, systemübergreifende Schnittstellenverträge, Protokollspezifikationen, Datenflussmodelle und End-to-End-Abläufe. Typische Fehlerzustände sind inkompatible Protokolle oder Datenformate, fehlerhafte Authentifizierung, falsche Aufrufreihenfolgen sowie unzureichende Behandlung von Timeouts und Ausfällen. Die Durchführung liegt häufig bei Testteams in Zusammenarbeit mit Integrations-, Betriebs- und externen Partnerteams. Dafür werden geeignete Testumgebungen oder realistische Service-Simulationen benötigt.
Abnahmetest
Der Abnahmetest klärt, ob das System für seinen beabsichtigten Einsatz geeignet ist. Durchgeführt wird er typischerweise vom Auftraggeber, von den Fachbereichen oder von echten Nutzerinnen und Nutzern. Ziel ist die formale Bestätigung, dass das System die vereinbarten Anforderungen erfüllt. Die Testbasis bilden Nutzeranforderungen, Verträge, Abnahmekriterien und regulatorische Vorgaben. Der Abnahmetest kommt in mehreren Ausprägungen vor: als Benutzerakzeptanztest (UAT), bei dem reale Anwender das System unter realistischen Bedingungen erproben, als Betriebsabnahmetest, als Alpha- und Beta-Test sowie als regulatorischer Abnahmetest in sicherheitskritischen Bereichen.
Der Abnahmetest stellt eine grundsätzlich andere Frage als der Systemtest. Der Systemtest fragt: “Funktioniert das System wie spezifiziert?” Der Abnahmetest fragt: “Ist das System das, was wir wirklich brauchen?” Der Unterschied wirkt subtil, hat aber handfeste Konsequenzen. Ein System kann sämtliche Systemtests bestehen und trotzdem an der Abnahme scheitern, wenn die Spezifikation die tatsächlichen Bedürfnisse der Nutzer nicht eingefangen hat. Wer beide Fragen verwechselt, hält am Ende eine korrekt gebaute Lösung für ein falsch verstandenes Problem in den Händen.
Testbasis je Teststufe
Jede Teststufe braucht eine eigene Grundlage, aus der sich ihre Testfälle ableiten lassen:
| Teststufe | Testbasis |
|---|---|
| Komponententest | Komponentenspezifikation, Entwurf, Sourcecode |
| Komponenten-Integrationstest | Softwarearchitektur, Komponentenspezifikation, interne Schnittstellen- und API-Dokumentation |
| Systemtest | Systemspezifikation, Anforderungsdokumente, Use Cases, Risikoliste |
| System-Integrationstest | Systemarchitektur, systemübergreifende Schnittstellenverträge, Protokolle, Datenflussmodelle |
| Abnahmetest | Nutzeranforderungen, Verträge, Abnahmekriterien, regulatorische Vorgaben |
Diese saubere Trennung verhindert einen Fehler, der in der Praxis erstaunlich verbreitet ist: Systemtestfälle aus dem Code abzuleiten statt aus den Anforderungen. Wer seine Testfälle aus dem Code gewinnt, beschreibt nur, was das System ohnehin tut. Er bestätigt sich selbst, statt zu prüfen, ob das System das Richtige tut. Erst Tests, die aus den Anforderungen entstehen, messen das System an seinem beabsichtigten Nutzen und nicht an seiner eigenen Implementierung.
Teststufen im V-Modell und in agilen Projekten
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
Das V-Modell ordnet jeder Entwicklungsphase eine Testphase zu und macht damit die Korrespondenz zwischen Bauen und Prüfen sichtbar. Komponentenspezifikation und Komponententest liegen auf einer Ebene, Systemspezifikation und Systemtest stehen sich gegenüber. Aus dieser Symmetrie folgt vor allem eine Einsicht: Testaktivitäten müssen früh geplant werden. Die Testbasis für den Systemtest entsteht in dem Moment, in dem die Systemspezifikation geschrieben wird. Nicht erst, wenn die Implementierung abgeschlossen ist.
In agilen Projekten laufen die Teststufen nicht mehr sequenziell. Sie überlappen und verlaufen parallel, ohne dass das zugrunde liegende Konzept dadurch an Gültigkeit verliert. Komponenten- und Komponenten-Integrationstests laufen automatisiert in der CI-Pipeline. Systemtests finden in Staging-Umgebungen statt, oft mehrfach pro Sprint. System-Integrationstests prüfen dort oder in eigenen Integrationsumgebungen die externen Schnittstellen und systemübergreifenden Abläufe. Abnahmetests geschehen in Sprint-Reviews oder in eigenen Validierungszyklen. Verschoben haben sich also die zeitliche Abfolge und die organisatorischen Grenzen, nicht die Stufen selbst. Shift-Left heißt in diesem Zusammenhang: Testaktivitäten früher im Entwicklungsprozess ansetzen. Systemtestfälle also dann schreiben, wenn die Anforderungen entstehen, nicht erst, wenn die Implementierung fertig ist. Das setzt allerdings voraus, dass Tester und Testteams früh in die Anforderungsarbeit eingebunden werden, statt am Ende der Kette auf fertige Artefakte zu warten.
Die Testpyramide als Ergänzung
Die Testpyramide nach Mike Cohn beschreibt eine andere Dimension als die Teststufen: die angestrebte Verteilung automatisierter Tests. Unten viele schnelle Unit-Tests, in der Mitte Service- und API-Integrationstests, oben wenige, langsame UI-Tests. Die Pyramide ist damit kein Gegenentwurf zu den Teststufen, sondern ein Automatisierungsmodell, das eine ganz eigene Frage beantwortet.
In der Praxis ergänzen sich beide Modelle, weil sie unterschiedliche Entscheidungen unterstützen. Die Teststufen legen fest, was auf welcher Ebene geprüft wird und wer die Verantwortung dafür trägt. Die Testpyramide gibt Orientierung, wie Automatisierungsinvestitionen zu priorisieren sind: viele stabile, schnelle Tests in den unteren Stufen, wenige, aber sorgfältig ausgewählte in den oberen. Wer die beiden verwechselt oder gegeneinander ausspielt, verliert am Ende die Stärke beider.
Am wertvollsten ist die Pyramide übrigens als Diskussionswerkzeug. Wenn ein Team sie für das eigene System durchspielt, wird sichtbar, welche Tests auf welcher Ebene laufen und warum. Die Ebenen sind dabei Inspiration, keine Vorgabe: Jedes Team schneidet sie so, wie es zum eigenen System passt. Und es muss am Ende auch keine Pyramide herauskommen. Wenn eine andere Verteilung sinnvoller ist, dann ist die andere Verteilung die richtige.
Wechselwirkungen: Teststufen und Testarten
Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen.
Teststufen und Testarten sind zwei unabhängige Dimensionen, die sich kreuzen, statt sich zu ersetzen. Alle Testarten lassen sich auf allen Teststufen anwenden. Was sich von Stufe zu Stufe ändert, ist nicht das Ob, sondern die Ausprägung. Auf Komponentenebene fragt Performance: Wie lange braucht eine einzelne Funktion unter Last? Auf Systemebene: Wie verhält sich das Gesamtsystem unter realistischen Lastprofilen? Dieselbe Eigenschaft, ganz unterschiedliche Fragen.
Eine Präzisierung gehört dazu: Testarten im engeren Sinn sind der funktionale Test, der nicht-funktionale Test, der Black-Box-Test und der White-Box-Test. Performance, Sicherheit und Usability sind Qualitätsmerkmale nach ISO 25010, die der nicht-funktionale Test prüft, also eine Ebene darunter. Für die Planung ist genau diese Merkmals-Ebene die nützliche, deshalb arbeitet die Schwerpunktmatrix in der Grafik mit ihr. Sie ist eine Schwerpunkttabelle, keine Zulässigkeitstabelle: Sie zeigt, wo ein Qualitätsmerkmal üblicherweise seinen Hauptfokus hat, nicht wo es allein geprüft werden darf.
Wer die Matrix als Verbotsliste liest, baut sich genau die Lücken ein, die sie aufdecken soll. Ein Sicherheitsproblem, das im Komponententest auffallen könnte, wartet sonst bis zum Systemtest. Und ein Performanceproblem, das in der Architektur wurzelt, lässt sich nach dem Systemtest kaum noch wirtschaftlich beheben. Als Schwerpunkttabelle gelesen, leistet die Matrix dagegen genau das, was ein Planungswerkzeug soll: Sie macht sichtbar, wo welches Merkmal wie intensiv geprüft wird, und erzwingt die Gespräche früh, die man sonst erst unter Zeitdruck führt.
Aus der Praxis
In Projekten, die ich begleite, ist die Teststufen-Matrix oft der erste gemeinsame Schritt. Nicht, weil das Modell irgendjemanden überraschen würde. Der Wert liegt im Gespräch: Kaum liegt die Matrix auf dem Tisch, wird sichtbar, welche Teststufen tatsächlich nicht stattfinden und warum. Diese Klarheit entsteht, bevor das Projekt richtig losläuft. Und genau dann ist sie am meisten wert.