Systemtest: das Gesamtsystem prüfen, bevor der Kunde es tut

Was ist der Systemtest?

Der Systemtest prüft das vollständige System als Ganzes gegen seine spezifizierten funktionalen und nicht-funktionalen Anforderungen, etwa Performance und Sicherheit. Er gehört zu den klassischen Teststufen. Häufig übernimmt ihn ein ganz oder teilweise unabhängiges Testteam, zwingend ist diese organisatorische Zuordnung jedoch nicht. Anders als der Abnahmetest bewertet er die Spezifikationstreue, nicht die Einsatztauglichkeit aus Kundensicht.

Der Schwerpunkt des Systemtests liegt darauf zu verifizieren, dass ein System als Ganzes die spezifizierten Anforderungen erfüllt. Deshalb steht meist das beobachtbare Verhalten an den Außengrenzen im Mittelpunkt. Black-Box-Verfahren passen gut zu diesem Ziel, sind aber weder exklusiv für den Systemtest noch dort vorgeschrieben. Strukturwissen und White-Box-Verfahren können ergänzen, wenn sie für das konkrete Testziel nützlich sind.

Der Perspektivwechsel vom einzelnen Baustein zum Gesamtsystem ist fundamental. Komponenten- und Integrationstests konzentrieren sich auf kleinere Testobjekte und deren Zusammenspiel; auch dort können Black-Box-, White-Box- und erfahrungsbasierte Verfahren zum Einsatz kommen. Im Systemtest rückt das Gesamtverhalten in den Vordergrund, so wie es Endbenutzer oder anbindende Systeme erleben.

Einordnung in die Teststufen

In der klassischen Darstellung steht der Systemtest nach Komponenten- und Komponenten-Integrationstest. Dazu kommt der System-Integrationstest als eigene Stufe vor dem Abnahmetest. Die Stufen können sich je nach Entwicklungsmodell zeitlich überlappen; sie sind keine zwingend starre Sequenz.

Nach unten grenzt er sich vom Integrationstest ab: Der prüft zwar das Zusammenspiel von Komponenten und Subsystemen, bewertet aber kein vollständiges System gegen fachliche Anforderungen. Nach oben grenzt er sich vom Abnahmetest ab, der aus Sicht der Auftraggeber oder Endbenutzer beurteilt, ob das System für den beabsichtigten Einsatz taugt. Die Integration mit externen Systemen wiederum ist nicht Sache des Systemtests, sondern des Systemintegrationstests. Der wird separat betrachtet.

Ziele und Qualitätsmerkmale

Ein sauber aufgesetzter Systemtest verfolgt mehrere Ziele zugleich. Er verifiziert, dass das System die spezifizierten funktionalen Anforderungen erfüllt. Er deckt Fehler auf, die sich erst auf Systemebene zeigen, weil einzelne Komponenten für sich korrekt arbeiten, ihr Zusammenspiel im Gesamtkontext aber nicht stimmt. Außerdem prüft er nicht-funktionale Qualitätsmerkmale, für die ein vollständiges System oder eine repräsentative Umgebung erforderlich ist.

Gerade der letzte Punkt wird in der Praxis gerne vernachlässigt. Viele nicht-funktionale Eigenschaften lassen sich bereits auf niedrigeren Teststufen untersuchen; ihre Bewertung hat dort jedoch einen anderen Fokus. Ende-zu-Ende-Leistungsverhalten, systemweite Zuverlässigkeit oder die Usability vollständiger Arbeitsabläufe benötigen häufig das Gesamtsystem und eine repräsentative Umgebung.

Testbasis

Als Testbasis dienen in erster Linie die funktionalen und nicht-funktionalen Anforderungen, ergänzt um User Stories, Geschäftsprozesse, Anwenderdokumentation und Akzeptanzkriterien. Fehlt eine strukturierte Anforderungsbasis oder ist sie lückenhaft, helfen Anwender und Fachabteilungen als Quelle weiter. Bei Systemablösungen und Migrationen kann sogar das Altsystem als Testorakel dienen, gegen das sich das neue Verhalten abgleichen lässt.

Die Qualität dieser Testbasis schlägt direkt auf die Qualität der Testfälle durch. Vage Formulierungen wie “Das System muss performant sein” oder “Die Applikation sollte leicht zu bedienen sein” lassen sich nicht in konkrete, prüfbare Testfälle übersetzen. Genau hier liegt ein oft unterschätzter Mehrwert der frühen Testfallerstellung: Sie zwingt dazu, Anforderungen zu konkretisieren, bevor die erste Zeile Code entstanden ist.

Testfallableitung

Für den Systemtest hat sich eine Kombination aus zwei Ansätzen bewährt. Sie ergänzen einander und gleichen ihre jeweiligen Schwächen aus.

Die strukturierte Testfallerstellung stützt sich auf systematische Black-Box-Verfahren. Äquivalenzklassenbildung und Grenzwertanalyse leiten Testfälle effizient aus den Anforderungen ab und sichern die nötige Breite der Abdeckung. Entscheidungstabellen bringen Ordnung in komplexe Geschäftslogik mit vielen Bedingungskombinationen. Zustandsübergangstests modellieren Systeme, die verschiedene Zustände durchlaufen, und prüfen gezielt die Übergänge dazwischen.

Die erfahrungsbasierte Testfallerstellung ergänzt diesen strukturierten Kern. Kein Anforderungsdokument bildet ein System vollständig ab; zwischen der ursprünglichen Idee und der aufgeschriebenen Anforderung entsteht immer ein Transferverlust. Erfahrene Tester füllen diese Lücken: Sie kennen typische Fehlermuster, nehmen kritische Randfälle aus der Praxis vorweg und denken die Erwartungen künftiger Anwender mit. Das wichtigste Werkzeug dafür ist das explorative Testen. Es findet gezielt jene Fehler, an denen strukturierte Testfälle systematisch vorbeilaufen.

Testumgebung

Die Testumgebung gehört zu den zentralen Herausforderungen im Systemtest. Für eine belastbare Aussage muss sie der Produktivumgebung möglichst nahekommen. Besonders bei nicht-funktionalen Tests ist das kritisch: Ein Performancetest auf einer deutlich schwächer ausgestatteten Umgebung liefert Messwerte, die sich schlicht nicht auf die Produktion übertragen lassen. Im schlimmsten Fall erzeugen sie eine falsche Sicherheit.

Virtualisierung und Cloud-Lösungen haben dieses Problem weitgehend entschärft. Liegt die Produktivumgebung als parametrisierte virtuelle Maschine oder als Container-Konfiguration vor, lässt sie sich für den Systemtest kosteneffizient replizieren. Infrastructure-as-Code macht die Umgebungskonfiguration zusätzlich versionierbar, reproduzierbar und nachvollziehbar.

Testdaten

Das Testdatenmanagement wird ab der Systemteststufe deutlich anspruchsvoller als auf den Ebenen darunter. Unit- und Integrationstests kommen meist mit überschaubaren, lokal definierten Datensets aus. Der Systemtest braucht dagegen häufig komplexere Konstellationen: angelegte Verträge, historische Datenbestände, über mehrere Domänenobjekte hinweg verknüpfte Datensätze.

Zwei Verfahren haben sich dafür etabliert. Echte Daten stammen als Datenabzug aus produktiven Systemen und werden bei Bedarf anonymisiert. Sie sind praxisnah und decken mitunter Konstellationen ab, die in Anforderungen und Testfällen nie explizit vorgesehen waren. Synthetische Testdaten werden gezielt für Grenzfälle und Sondersituationen erzeugt: Geburtstage am 29. Februar, Postleitzahlen mit führender Null, maximale Feldlängen. Also genau jene Kombinationen, die in Produktivdaten selten vollständig vorkommen.

Methoden und Werkzeuge

Im Systemtest sind Black-Box-Verfahren verbreitet, weil Anforderungen und beobachtbares Verhalten meist die Testbasis bilden. Erfahrungsbasierte und, je nach Ziel, strukturorientierte Verfahren ergänzen sie. Das Werkzeugspektrum richtet sich nach der geprüften Schnittstelle: Für GUI-basierte Anwendungen kommen etwa Playwright, Selenium oder Cypress zum Einsatz, auf API-Ebene REST-assured, Postman oder Karate.

Testmanagement-Werkzeuge unterstützen Planung, Testfallverwaltung und Fehlerdokumentation: eigenständige wie TestRail oder Jira in Kombination mit Erweiterungen wie Xray. Ein strukturiertes Fehlermanagement ist auf Systemtestebene besonders wichtig: Fehler haben hier oft systemübergreifende Ursachen, und die Kommunikation zwischen Tester, Entwickler und Fachbereich muss entsprechend gezielt gesteuert werden.

Testautomatisierung im Systemtest

Die Testautomatisierung auf Systemtestebene hat sich durch moderne Frameworks erheblich weiterentwickelt. GUI-Tests galten lange als fragil und wartungsintensiv. Playwright und vergleichbare Frameworks haben dieses Stabilitätsproblem weitgehend gelöst, und API-Tests auf Systemebene sind ohnehin wartungsärmer und liefern schnellere Rückmeldung.

Für Regressionstests, die in jedem Release-Zyklus erneut laufen, lohnt sich die Automatisierung fast immer. Exploratives Testen, Usability-Tests und alle Szenarien, die eine subjektive Benutzererfahrung beurteilen, bleiben dagegen sinnvollerweise in menschlicher Hand.

Systemtest in agilen Projekten

Das Modell der Teststufen stammt aus einer Zeit vor den agilen Vorgehensmodellen und wird in Scrum-Kontexten deshalb gerne ignoriert. Zu Unrecht. Die inhaltlichen Ziele des Systemtests gelten auch in agilen Kontexten: Das Gesamtverhalten wird gegen die relevanten Anforderungen geprüft, Testdaten werden vorbereitet und eine geeignete Testumgebung sichergestellt. Welche Techniken, Rollen und Grade von Unabhängigkeit dafür sinnvoll sind, entscheidet der Kontext.

Was sich ändert, ist der Rhythmus. Systemtests können innerhalb eines Sprints, kontinuierlich in geeigneten Umgebungen oder in eigenen Validierungszyklen stattfinden. Die Testpyramide liefert dazu eine ergänzende Perspektive: Komplexe Ende-zu-Ende-Tests werden selektiv und gezielt eingesetzt, nicht als Ersatz für solide Komponenten- und Integrationstests.

Typische Fehlerklassen und Risiken

Bestimmte Fehler werden typischerweise erst auf Systemebene sichtbar:

• Funktionale Abweichungen zwischen Anforderung und Systemverhalten, die auf den niedrigeren Teststufen nicht erkennbar waren.
• Nicht-funktionale Mängel wie Performance-Engpässe unter Last, Speicherlecks bei langer Laufzeit oder Timeouts bei komplexen Transaktionen.
• Datenkonsistenzprobleme, die erst bei realistischen Datenvolumina auftreten.
• Fehlerhafte Grenzwert- und Fehlerbehandlung bei ungültiger Eingabe oder unerwarteten Zuständen.
• Verhalten unter Ausnahmebedingungen, etwa bei fehlender Netzwerkverbindung, Systemüberlastung oder fehlerhaften Daten aus externen Quellen.

In der Praxis legt der Systemtest damit häufig die Lücken der unteren Teststufen offen. Instabiles oder inkonsistentes Verhalten auf Systemebene deutet fast immer auf fehlende Robustheit im Komponenten- oder Integrationstest hin. Diese Erkenntnisse kommen spät und sind teuer zu beheben. Genau das ist das stärkste Argument dafür, die anderen Teststufen nicht zu überspringen.

Grenzen des Ansatzes

Der wesentliche Nachteil des Systemtests folgt direkt aus seinem umfangreichen Testobjekt: Ein ausreichend vollständiges System und eine geeignete Umgebung stehen oft später bereit als einzelne Komponenten. Die Vorbereitung von Testfällen, Testdaten und Umgebungen kann und sollte dennoch früh beginnen.

Für interne Qualitätsattribute wie Codekomplexität, Wartbarkeit oder die Testabdeckung des Quellcodes ist der Systemtest ebenfalls das falsche Mittel. Diese Aspekte gehören zu den unteren Teststufen und verlangen andere Werkzeuge und andere Metriken.

Aus der Praxis

In vielen Projekten ist der Systemtest die erste Teststufe, auf der überhaupt ernsthaft getestet wird. Das macht ihn wertvoll, aber auch zum Sammelbecken für Qualitätsprobleme, die man viel früher hätte erkennen können. Die Erkenntnisse sind richtig und wichtig. Nur steigen die Kosten für ihre Behebung mit jeder Teststufe, die man vorher übersprungen hat.