Katalog
concept#Qualitätssicherung#Softwareentwicklung#DevOps#Zuverlässigkeit

Test Levels

Gliederung von Testarten nach Zweck und Umfang (Unit, Integration, System, Akzeptanz) zur Strukturierung von Teststrategien und Verantwortlichkeiten.

Test Levels beschreibt die Hierarchie von Tests (Unit, Integration, System, Akzeptanz) zur systematischen Qualitätsprüfung von Software.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Design
  • Fortgeschritten

Technischer Kontext

CI-Server (z. B. Jenkins, GitHub Actions)Testframeworks (z. B. JUnit, pytest)Mocking- und Stubbing-Tools

Prinzipien & Ziele

Trennung der Testebenen nach Granularität und UmfangSchnelles Feedback näher an der ImplementierungAutomatisierung dort, wo Wiederholbarkeit und Stabilität wichtig sind
Umsetzung
Team, Domäne

Use Cases & Szenarien

Kompromisse

  • Zu viel Fokus auf einer Ebene und Vernachlässigung anderer
  • Unzureichende Testdaten und Umgebungsspezifikationen
  • Erhöhte CI-Zeiten durch fehlende Parallelisierung
  • Keep tests fast and deterministic auf Unit-Ebene
  • Isoliere Integrations- und E2E-Tests in speziellen Umgebungen
  • Nutze Testdatenmanagement und Mocking für Stabilität

I/O & Ressourcen

  • Anforderungen und Akzeptanzkriterien
  • Testumgebungen und Testdaten
  • CI/CD-Integration und Testframeworks
  • Testberichte und Fehlerrückmeldungen
  • Regressionsschutz durch automatisierte Suiten
  • Freigabekriterien basierend auf Testresultaten

Beschreibung

Test Levels beschreibt die Hierarchie von Tests (Unit, Integration, System, Akzeptanz) zur systematischen Qualitätsprüfung von Software. Es definiert Zwecke, Umfang und Verantwortlichkeiten auf jeder Ebene und erleichtert Teststrategie, Automatisierungsgrad und Fehlerlokalisierung. Es unterstützt Priorisierung und Ressourceneinsatz.

✔

  • Bessere Fehlerlokalisierung durch klare Verantwortungsgrenzen
  • Effizientere Teststrategie und Ressourcennutzung
  • Skalierbare Automatisierungspfade pro Ebene

✖

  • Überspezifikation einzelner Ebenen kann Aufwand erhöhen
  • Flaky Tests auf Integrations- oder E2E-Ebene sind schwer zu debuggen
  • Nicht alle Fehler werden auf Unit-Ebene sichtbar

  • Durchschnittliche Testlaufzeit

    Mittlere Dauer kompletter Testläufe in der CI-Pipeline.

  • Fehlerlokalisierungszeit

    Zeit vom Fehlerauftreten bis zur Identifikation der betroffenen Komponente.

  • Testabdeckungsgrad

    Anteil des Quellcodes, der durch automatisierte Tests abgedeckt ist.

Unit-Testing in Microservice A

Satz von schnellen Unit-Tests zur Absicherung von Service-Logik und DTO-Transformationen.

Integrationstests für Zahlungsabwicklung

Testläufe gegen simulierte Zahlungs-Gateways zur Validierung End-to-End-Integrationen.

Akzeptanztest für Web-Checkout

Geschäftsgetriebene Szenarien prüfen Checkout-Flows mit realistischen Testdaten.

1

Analyse bestehender Testabdeckung und Identifikation von Lücken

2

Definition von Zielen pro Testebene (z. B. Laufzeit, Coverage)

3

Automatisierung priorisierter Tests und Integration in CI

4

Monitoring der Testmetriken und kontinuierliche Verbesserung

⚠️ Technische Schulden & Engpässe

  • Langsame, nicht parallele Testpipelines
  • Fehlende oder unzuverlässige Testdatenkenntnis
  • Hoher Legacy-Test-Wartungsaufwand
Lange TestlaufzeitenFlaky TestsKomplexe Testumgebungen
  • E2E-Tests für UI-Details, die häufig wechseln
  • Mocks an falschen Integrationsgrenzen einsetzen
  • Unit-Tests als Ersatz für Integrationsvalidierung
  • Unklare Zuständigkeiten für Testarten
  • Fehlende Pflege veralteter Tests
  • Überkomplizierte Testdatenaufbereitung
Testdesign und TestfallentwicklungAutomatisierungsentwicklungFehlerdiagnose und Debugging
Schnelle Feedback-Zyklen für EntwicklerSkalierbare CI/CD-PipelinesIsolierbarkeit von Komponenten zur Fehlerdiagnose
  • • Begrenzte CI-Ressourcen
  • • Legacy-Code ohne Tests
  • • Beschränkter Zugriff auf externe Integrationen während Tests