Teststufen: Vom Unit-Test bis zum Abnahmetest

Was sind Teststufen?

Teststufen beschreiben aufeinanderfolgende Phasen im Testprozess. Jede Stufe nimmt einen anderen Aspekt des Softwaresystems in den Blick. Das ISTQB definiert eine Teststufe als “eine spezifische Instanziierung eines Testprozesses”. Das klingt trocken, steckt aber voller Praxis: 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 Defekt 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. Im Systemtest wären sie nur noch schwer lokalisierbare Symptome. Schnittstellenprobleme werden im Integrationstest sichtbar, Systemfehler und nicht-funktionale Mängel im Systemtest. Und ob das System am Ende wirklich das leistet, was der Auftraggeber braucht, klärt erst der Abnahmetest. So entsteht eine Kette: Jede Stufe setzt die vorige voraus und bereitet die nächste vor.

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 vier klassischen Teststufen

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. Das ist kein technisches Detail, sondern der Kern der Sache: Ein Test, der nicht isoliert läuft, ist kein echter Komponententest. Er prüft immer auch die Abhängigkeiten mit und verliert damit genau die Aussagekraft, für die er gedacht ist. 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.

Integrationstest

Der Integrationstest prüft das Zusammenspiel von Komponenten und Subsystemen. Also genau den Bereich, in dem einzeln funktionierende Bausteine unerwartet aneinander scheitern. Das ISTQB unterscheidet zwei Varianten: den Komponenten-Integrationstest, der die Interaktion zwischen integrierten Komponenten innerhalb eines Systems bewertet, und den System-Integrationstest, der das Zusammenwirken mehrerer Systeme und externer Schnittstellen prüft, etwa APIs, Datenbanken und Drittsysteme.

Die Testbasis bilden Architekturentwürfe, Schnittstellenbeschreibungen und API-Dokumentationen. Typische Fehlerzustände: fehlkommunizierte Daten, falsche Aufrufsequenzen, inkompatible Datenformate und eine Fehlerbehandlung, die über Komponentengrenzen hinweg nicht mehr greift. Verantwortet wird der Integrationstest häufig gemeinsam von Entwicklung und Test. In Continuous-Integration-Pipelines läuft er automatisiert bei jedem Build mit. Bewährt hat sich ein inkrementelles Vorgehen: erst die kleinsten sinnvollen Gruppen integrieren und prüfen, dann den Umfang schrittweise erweitern. Wer alles auf einmal zusammenschaltet, steht im Fehlerfall vor einem undurchschaubaren Knäuel.

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.

Verantwortlich ist ein dediziertes Testteam, das unabhängig von der Entwicklung arbeitet. Diese Unabhängigkeit ist kein bürokratisches Ritual und kein Misstrauensvotum. Sie ist ein Wirkprinzip: Ein anderer Blickwinkel findet andere Fehler. Wer eine Software gebaut hat, ist gegenüber ihren blinden Flecken naturgemäß am schlechtesten gewappnet.

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. Das ISTQB unterscheidet mehrere Ausprägungen: den Benutzerakzeptanztest (UAT), bei dem reale Anwender das System unter realistischen Bedingungen erproben, den Betriebsabnahmetest, Alpha- und Beta-Tests sowie regulatorische Abnahmetests 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:

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

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 Integrationstests laufen automatisiert in jeder CI-Pipeline. Systemtests finden in Staging-Umgebungen statt, oft mehrfach pro Sprint. 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.

Wechselwirkungen: Teststufen und Testarten

Teststufen und Testarten sind zwei unabhängige Dimensionen, die sich kreuzen, statt sich zu ersetzen. Eine Testart wie der Performance-Test lässt sich grundsätzlich auf jeder Teststufe durchführen, nimmt dort aber jeweils eine andere Gestalt an. 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.

Diese Matrix ist kein starres Schema, sondern ein Planungswerkzeug. Sie macht sichtbar, welche Qualitätseigenschaften auf welcher Stufe geprüft werden, und deckt Lücken auf, solange sie sich noch günstig schließen lassen. Gerade nicht-funktionale Qualitätsmerkmale werden in frühen Teststufen gern vernachlässigt, bis sie spät und teuer auffallen. Ein Performanceproblem, das in der Architektur wurzelt, lässt sich nach dem Systemtest kaum noch wirtschaftlich beheben. Die Matrix erzwingt genau 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.