Teststufen

Die vier Stufen der Softwareprüfung

Um in komplexen Softwareprojekten den Überblick zu behalten und Fehlerkosten gering zu halten, wird Code nicht erst am Ende unstrukturiert getestet. Stattdessen folgt die Qualitätssicherung einer klaren Hierarchie. Wie die zugehörige Grafik veranschaulicht, bauen die Teststufen systematisch aufeinander auf – oft dargestellt als Testpyramide oder V-Modell. Du arbeitest dich von der kleinsten Code-Einheit bis hin zum fertigen Gesamtprodukt vor.

Diese Struktur umfasst vier aufeinander aufbauende Stufen, die jeweils ein spezifisches Ziel und eine eigene Perspektive auf die Software haben:

1. Komponententests (Unit Tests)
2. Integrationstests
3. Systemtests
4. Abnahmetests (Acceptance Tests)

Komponententests (Unit Tests): Die kleinsten Bausteine isolieren

Auf der untersten Ebene prüfst du die kleinsten testbaren Einheiten deines Codes – meist einzelne Funktionen oder Klassen – völlig isoliert. Das Ziel ist es, die rein technische Korrektheit der Logik sicherzustellen.

Da Funktionen oft externe Abhängigkeiten haben (z. B. eine Datenbankanbindung), nutzt du Techniken wie Mocking. Ein Mock ist ein Dummy-Objekt, das die echte Datenbank simuliert. So stellst du sicher, dass ein fehlschlagender Test wirklich an einem Fehler in deiner Funktion liegt und nicht an einem ausgefallenen Datenbankserver.

Beispiel: Du testest eine Funktion zur Netto-Berechnung isoliert mit verschiedenen Eingabewerten.

def berechne_netto(brutto, steuersatz):
    return brutto / (1 + steuersatz)

def test_berechne_netto():
    # Die Logik wird isoliert und automatisiert geprüft
    assert berechne_netto(119, 0.19) == 100.0
    assert berechne_netto(107, 0.07) == 100.0

Integrationstests: Das Zusammenspiel der Module

Sobald die einzelnen Komponenten fehlerfrei arbeiten, prüfen Integrationstests, ob sie auch im Verbund korrekt kommunizieren. Der Fokus liegt hier auf den Schnittstellen und dem Datenfluss zwischen den Modulen. Dafür gibt es drei gängige Strategien:

• Big Bang: Alle Module werden gleichzeitig zusammengesetzt und getestet. Das geht schnell, aber bei Fehlern ist die genaue Ursache extrem schwer zu lokalisieren.
• Top-Down: Du beginnst bei den übergeordneten, steuernden Modulen und arbeitest dich nach unten vor. Noch fehlende untergeordnete Module werden durch Platzhalter (Stubs) simuliert.
• Bottom-Up: Du startest bei den Basisfunktionen (z. B. dem Datenbankzugriff) und baust das System nach oben auf. Fehlende übergeordnete Module werden durch Testtreiber (Drivers) simuliert.

Beispiel: Ein Integrationstest prüft, ob das Modul "Warenkorb" die korrekte Endsumme an das Modul "Bezahlschnittstelle" übergibt.

Systemtests: Das Gesamtwerk im Realitätscheck

Im Systemtest wird das gesamte, vollständig integrierte Produkt als eine Einheit geprüft. Hier validierst du, ob die Software genau das tut, was ursprünglich gefordert war.

Dabei testest du sowohl funktionale Anforderungen (Was soll die Software können?) als auch nicht-funktionale Anforderungen (Wie schnell, sicher und zuverlässig ist sie?). Zwingend notwendig ist hierfür eine produktionsnahe Testumgebung. Das bedeutet, dass Hardware, Betriebssystem und Netzwerkkonfiguration der späteren Live-Umgebung exakt entsprechen müssen, um verlässliche Aussagen treffen zu können.

Beispiel: In einer produktionsnahen Umgebung wird getestet, ob eine Banking-App eine Überweisung korrekt verbucht (funktional) und ob das System auch bei 10.000 parallelen Benutzer:innen stabil bleibt (nicht-funktional).

Abnahmetests (UAT): Das finale Urteil der Anwendenden

Die letzte Stufe ist der User Acceptance Test (UAT) oder Abnahmetest. Hier wechselt die Perspektive: Die Software wird nicht mehr von Entwickelnden, sondern von den tatsächlichen Endanwendenden oder Auftraggebenden geprüft.

Das Hauptziel ist die Validierung der Gebrauchstauglichkeit (Usability) und der realen Geschäftsprozesse. Es wird die Frage beantwortet: "Haben wir das richtige System für den Arbeitsalltag gebaut?" Ein erfolgreicher Abnahmetest bestätigt die Vertragserfüllung und ist in der Regel die rechtliche Voraussetzung dafür, dass das Projekt offiziell abgeschlossen und die Software bezahlt wird.

Beispiel: Ein Team von Sachbearbeitenden nutzt die neue Software für einen simulierten Arbeitstag, um zu bestätigen, dass alle Menüs logisch aufgebaut sind und sie ihre täglichen Aufgaben effizient erledigen können.