Unit-Test, Integrationstest, Abnahmetest – wer testet eigentlich was, und was hat das Pflichtenheft damit zu tun?

Die Verwirrung ist völlig normal, weil in der Praxis wirklich alles „testen“ heißt. Die Prüfungslogik ist aber sehr sauber, wenn man sie einmal an der richtigen Frage aufhängt – und die lautet: Gegen welches Dokument wird geprüft? Jede Teststufe hat ihr eigenes Bezugsdokument. Damit beantwortet sich auch dein Pflichtenheft-Rätsel.

Die vier Stufen von unten nach oben:

1. Unit- oder Komponententest. Prüfgegenstand: der einzelne Baustein – eine Klasse, eine Funktion, ein Modul, isoliert von allem anderen. Bezugsdokument: die technische Feinspezifikation bzw. der Entwurf. Wer: die Entwicklerin selbst. Typischerweise automatisiert und bei jedem Build ausgeführt.
2. Integrationstest. Prüfgegenstand: das Zusammenspiel der Bausteine, also die Schnittstellen. Bezugsdokument: der Grob- bzw. Architekturentwurf. Und hier liegt die Antwort auf deine erste Frage: Nein, das ist nicht „mehrere Unit-Tests zusammen“. Jede Komponente kann für sich fehlerfrei sein, und trotzdem kracht es an der Schnittstelle – vertauschte Parameter, unterschiedliche Einheiten, unterschiedliches Datumsformat, ein Modul liefert Meter, das andere erwartet Zentimeter. Genau diese Fehlerklasse findet ein Unit-Test nie, weil er die Nachbarn durch Platzhalter ersetzt.
3. Systemtest. Prüfgegenstand: das vollständige System in einer produktionsnahen Umgebung. Bezugsdokument: das Pflichtenheft. Getestet wird gegen die Auftragnehmersicht dessen, was gebaut werden sollte – inklusive der nicht-funktionalen Anforderungen: Antwortzeiten, Last, Sicherheit, Bedienbarkeit. Wer: eine Testinstanz beim Auftragnehmer, idealerweise nicht dieselben Personen, die den Code geschrieben haben.
4. Abnahmetest. Prüfgegenstand: erfüllt das System den Auftrag? Bezugsdokument: das Lastenheft. Wer: der Kunde bzw. die Fachabteilung, meist in dessen Umgebung und mit echten Fachdaten. Damit ist auch deine zweite Frage beantwortet – der Abnahmetest ist die einzige Stufe, die per Definition nicht beim Entwicklungsteam liegt, denn an ihm hängt die Abnahme und damit die Zahlung.

Und jetzt das V-Modell, das plötzlich Sinn ergibt: Der linke Ast beschreibt die Spezifikation von grob nach fein (Lastenheft, Pflichtenheft, Architektur, Feinentwurf), der rechte Ast das Testen von fein nach grob. Jede Teststufe rechts liegt auf derselben Höhe wie „ihr“ Dokument links. Deshalb wurde bei euch in der Vorlesung das Pflichtenheft im Test-Kapitel erwähnt: Es ist nicht nur ein Startdokument, sondern der Maßstab, an dem später gemessen wird. Wenn du dir für die Klausur nur eine Sache merkst, dann diese Zuordnung – daraus kannst du alles andere herleiten.

Kleiner Zusatz, weil es gern gefragt wird: Man unterscheidet zusätzlich Blackbox (nur Ein- und Ausgabeverhalten, ohne Kenntnis des Innenlebens – typisch für System- und Abnahmetest) und Whitebox (mit Kenntnis der Code-Struktur, Ziel etwa Zweigüberdeckung – typisch für Unit-Tests).

Daniels Zuordnung ist genau das, was in der Klausur verlangt wird. Ich ergänze die Praxisseite – die erklärt auch, warum bei euch in der Firma alles „testen“ heißt.

Was in der Realität dazukommt:

• Regressionstest. Keine eigene Stufe, sondern ein Anlass: Nach jeder Änderung wird geprüft, ob etwas kaputtgegangen ist, das vorher funktioniert hat. Das ist der Grund, warum automatisierte Tests so wertvoll sind – ein Mensch führt 400 Prüfschritte nicht jede Woche erneut aus, eine Pipeline schon.
• Smoke-Test. Der schnelle Grundcheck nach einer Auslieferung: Startet die Anwendung, kommt die Anmeldeseite, geht ein Beispielvorgang durch? Fünf Minuten, bevor man mit dem Rest anfängt.
• Testfall ist nicht gleich Testdaten. Der Testfall beschreibt Vorbedingung, Eingabe, erwartetes Ergebnis und Nachbedingung. Das erwartete Ergebnis muss vorher feststehen – sonst testet man nicht, sondern schaut zu, was passiert, und findet es dann plausibel. Klingt banal, ist in der Praxis der häufigste Kardinalfehler.

Warum man früh testet – die Zehnerregel der Fehlerkosten. Die Faustformel besagt: Ein Fehler, der in der Anforderungsphase entdeckt wird, kostet 1. In der Entwicklung das Zehnfache, im Systemtest das Hundertfache, beim Kunden im Betrieb das Tausendfache. Die genauen Zahlen sind eine Faustregel, kein Naturgesetz, aber die Größenordnung stimmt und wird gern abgefragt. Der Grund ist simpel: Je später der Fund, desto mehr hängt bereits an dem Fehler – Code, Dokumentation, Schulungsunterlagen, Daten in der Produktivdatenbank.

Und noch ein Satz, den man sich merken sollte: Testen kann die Anwesenheit von Fehlern zeigen, nie ihre Abwesenheit beweisen. Vollständiges Testen ist bei realen Systemen nicht möglich – schon eine Handvoll Eingabefelder erzeugt astronomisch viele Kombinationen. Deshalb arbeitet man mit Äquivalenzklassen (Eingaben, die sich gleich verhalten sollten, in Gruppen zusammenfassen und je einen Vertreter testen) und mit der Grenzwertanalyse (genau an den Rändern testen: 17, 18 und 19 Jahre bei einer Altersgrenze von 18). Erfahrungsgemäß sitzen dort die meisten Fehler.

Ich schreibe gerade selbst Tests im Praxisprojekt und ergänze noch drei Begriffe, die bei uns in der Klausur direkt nach den Teststufen dran waren.

1. Die Testpyramide. Sie beschreibt, wie viele Tests man auf welcher Ebene haben sollte: unten viele Unit-Tests (schnell, billig, genau lokalisierbar), in der Mitte weniger Integrationstests, oben nur wenige End-to-End-Tests über die Oberfläche (langsam, wartungsintensiv, bei Fehlschlag schwer zu deuten). Das Gegenbild heißt Eistüte: kaum Unit-Tests, dafür Hunderte manuelle Klicktests. Das ist der Zustand, in dem jede Änderung zur Mutprobe wird.

2. Stub und Mock. Daniel hat geschrieben, dass Unit-Tests die Nachbarkomponenten durch Platzhalter ersetzen. Davon gibt es zwei wichtige Sorten:

• Ein Stub liefert nur feste Antworten, damit der Test überhaupt laufen kann – etwa ein Wechselkursdienst, der immer 1,10 zurückgibt.
• Ein Mock prüft zusätzlich, ob und wie er aufgerufen wurde – etwa ob beim Abschluss einer Bestellung genau eine Bestätigungsmail ausgelöst wurde.

Merksatz: Stub = Zustand prüfen, Mock = Verhalten prüfen.

3. Testgetriebene Entwicklung (TDD). Erst den Test schreiben, der fehlschlägt, dann gerade so viel Code, dass er grün wird, dann aufräumen – im Kreislauf „Red, Green, Refactor“. Das passt übrigens schön zu Tobis Hinweis, dass das erwartete Ergebnis vorher feststehen muss: Bei TDD ist das gar nicht anders möglich.