Teststufen

Die Hierarchie der Teststufen

Du weißt bereits, dass frühzeitiges Testen entscheidend ist, um die Fehlerkosten gering zu halten. Um den Überblick in komplexen Systemen zu bewahren, wird in der Softwareentwicklung nicht "einfach alles auf einmal" geprüft. Stattdessen folgt man oft einer klaren Hierarchie, dem sogenannten V-Modell der Teststufen. Man arbeitet sich dabei von der kleinsten Code-Einheit bis hin zum fertigen Gesamtprodukt vor:

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

Jede Stufe hat ein eigenes Ziel, eine spezifische Testumgebung und unterschiedliche Verantwortlichkeiten, um sicherzustellen, dass sowohl die technische Qualität als auch die fachlichen Anforderungen erfüllt werden.

Komponententests: Die kleinsten Einheiten im Visier

Auf der untersten Ebene, den Unit Tests, wird die kleinste testbare Einheit einer Software (meist eine einzelne Funktion oder eine Klasse) isoliert geprüft.

• Ziel: Die technische Korrektheit einer isolierten Logik sicherstellen.
• Isolierung durch Mocking: Da Komponenten oft voneinander abhängen (z. B. eine Funktion benötigt Daten aus einer Datenbank), nutzt man Mocks oder Stubs. Das sind "Dummy-Objekte", die das Verhalten der echten Umgebung simulieren. So wird garantiert, dass ein Testfehlschlag wirklich an der Komponente liegt und nicht an einer fehlerhaften externen Datenbank.
• Verantwortung: Diese Tests werden meist direkt von den Entwickelnden geschrieben und automatisiert ausgeführt.

Beispiel: Eine Funktion berechne_rabatt() wird mit verschiedenen Werten (z. B. 0 €, 100 €, negativer Betrag) gefüttert, um zu sehen, ob sie mathematisch korrekt reagiert.

# Beispiel für einen Unit Test in Python
def berechne_netto(brutto, steuersatz):
    return brutto / (1 + steuersatz)

def test_berechne_netto():
    # Wir prüfen isoliert die mathematische Logik
    assert berechne_netto(119, 0.19) == 100.0
    assert berechne_netto(107, 0.07) == 100.0

Integrationstests: Wenn Einzelteile zusammenfinden

Sobald die einzelnen Bausteine funktionieren, wird geprüft, ob sie auch im Verbund fehlerfrei arbeiten. Integrationstests konzentrieren sich auf die Schnittstellen und den Datenfluss zwischen den Modulen. Hierbei gibt es verschiedene Strategien:

• Big Bang: Alle Module werden gleichzeitig zusammengesetzt und getestet.
  • Nachteil: Bei Fehlern ist die Ursache extrem schwer zu lokalisieren.
• Top-Down: Man beginnt bei den steuernden Modulen (oben) und arbeitet sich nach unten vor. Fehlende untere Module werden durch Platzhalter (Stubs) ersetzt.
  • Vorteil: Das Skelett des Systems wird früh sichtbar.
• Bottom-Up: Man startet bei den Basisfunktionen (unten, z. B. Datenbankzugriffe) und baut schrittweise nach oben auf. Fehlende obere Module werden durch Testtreiber (Driver) ersetzt.
  • Vorteil: Kritische Basisfunktionen werden sehr gründlich geprüft.

Beispiel: Ein Online-Shop testet, ob das "Warenkorb-Modul" die Artikeldaten korrekt an das "Bezahlschnittstellen-Modul" übergibt.

Systemtests: Das Gesamtwerk im Realitätscheck

Im Systemtest wird das gesamte, integrierte Produkt als Einheit gegen die ursprünglichen funktionalen Anforderungen (Was soll die Software tun?) und nicht-funktionalen Anforderungen (Performance, Sicherheit, Zuverlässigkeit) geprüft.

• Umgebung: Die Tests finden in einer speziellen Testumgebung statt, die der späteren Produktionsumgebung (Hardware, Betriebssystem, Last) so ähnlich wie möglich ist.
• Prüfumfang: Es werden komplette Geschäftsprozesse von Anfang bis Ende (End-to-End) durchgespielt.
• Verantwortung: Meist übernimmt hier ein unabhängiges Qualitätssicherungsteam (QA), um die nötige Objektivität zu wahren.

Beispiel: In einer Banking-App wird geprüft, ob eine Überweisung unter maximaler Last (10.000 parallele User) innerhalb von 2 Sekunden verarbeitet wird und alle Sicherheitsprotokolle eingehalten werden.

Abnahmetests: Das finale Urteil der Nutzenden

Die letzte Stufe ist der User Acceptance Test (UAT). Hier wird die Software aus der Perspektive der Endanwendenden oder Auftraggebenden beurteilt.

• Ziel: Sicherstellen, dass die Software für den täglichen Gebrauch tauglich ist und die vertraglich vereinbarten Ziele erfüllt. Es geht um die Validierung: "Haben wir das richtige System für die Anwendenden gebaut?"
• Perspektive: Im Fokus stehen die Gebrauchstauglichkeit (Usability) und die Abdeckung der realen Arbeitsabläufe.
• Bedeutung: Ein erfolgreicher Abnahmetest ist meist die rechtliche Voraussetzung für die Projektabnahme und die finale Bezahlung.

Beispiel: Ein Team von Sachbearbeitenden nutzt die neue Software für einen Test-Arbeitstag, um zu bestätigen, dass alle Menüpunkte logisch angeordnet sind und ihre täglichen Aufgaben effizient erledigt werden können.