Antwort.

Hintergrund:

Testabdeckung (test coverage) ist eine der wichtigsten Kennzahlen für die Qualität von Tests. Die Strategien zur Testabdeckung entstanden bereits zu Beginn der Automatisierung, als die Anzahl der Tests schnell wuchs und es unmöglich wurde, manuell unbeaufsichtigte Szenarien zu verfolgen. Seitdem haben sich die Ansätze von intuitiven bis hin zu strengen analytischen Methoden weiterentwickelt, wobei sowohl Anforderungsverfolgung als auch Code Coverage Tools und die Kontrolle über die Testpyramide eingesetzt werden.

Problem:

Eine gleichmäßige und bewusste Testabdeckung ist aufgrund der verschiedenen Testarten (Unit, Integration, E2E), deren unterschiedlicher Ausführungsgeschwindigkeit, der Supportkosten sowie der Notwendigkeit eines Ausgleichs zwischen ROI und Risiken übersehener Defekte eine schwierige Aufgabe.
Oft besteht ein falsches Gefühl der vollständigen Sicherheit nur durch einen hohen Prozentsatz an Codeabdeckung, während "Lücken" in der Geschäftslogik oder den Nutzungsszenarien ignoriert werden.

Lösung:

Es ist notwendig, eine Kombination verschiedener Techniken zu verwenden: Code Coverage, Traceability Matrix, risikobasierte Tests.
Es ist wichtig, die Strategie mit dem Entwicklungsteam und der Geschäftseinheit abzustimmen, um die realen Prioritäten zu verstehen.
Eine Schlüsselpraktik ist die regelmäßige Prüfung der Abdeckung (sowohl manuell als auch automatisch), die Anpassung der Prioritäten und der Verzicht auf die Idee der "hundertprozentigen Codeabdeckung" zugunsten eines sinnvollen, szenario- und risikoorientierten Ansatzes.

Wesentliche Merkmale:

Einsatz mehrerer Abdeckungsarten: statement, branch, condition, feature, requirements coverage.
Integration der Techniken Traceability Matrix und Code Coverage für maximale Vollständigkeit.
Regelmäßige Überprüfung der Strategie und automatische Berichtserstellung.

Fangfragen.

Kann eine hohe Codeabdeckung die Qualität des Produkts vollständig garantieren?

Nein, das kann sie nicht. Ein hoher Prozentsatz an Codeabdeckung (z. B. 95 %) bedeutet oft, dass nur bestimmte Teile des Codes durch Tests "durchlaufen" wurden, aber das garantiert nicht die Richtigkeit der Geschäftslogik oder der Nutzungsszenarien.

Sollte man immer auf 100% Codeabdeckung abzielen?

Nein. Das Streben nach hundertprozentiger Abdeckung erhöht die Supportkosten und erfordert manchmal, Tests für unerhebliche oder unerreichbare Teile zu schreiben. Besser ist es, Prioritäten basierend auf Risiko und Nutzen zu setzen.

Reichen nur Unit-Tests aus, um eine zuverlässige Abdeckung zu gewährleisten?

Nein. Unit-Tests decken keine Integration Szenarien und die Interaktion von Komponenten ab. Verschiedene Testarten müssen gemäß der Testpyramide kombiniert werden.

Typische Fehler und Anti-Pattern

Blinder Drang nach einem hohen Prozentsatz an Codeabdeckung
Ignorieren der Abdeckung von Nutzungsszenarien und Anforderungen
Fehlende Beteiligung des Geschäftsteams bei der Festlegung der Abdeckungsprioritäten
Alle Tests einer Art: nur Unit- oder nur E2E-Tests

Beispiel aus dem Leben

Negativer Fall

Das Team implementierte eine Pipeline mit einer obligatorischen 90%igen Testabdeckung für jeden Pull Request. Infolgedessen traten "leere" Tests auf, die Zeilen abdeckten, aber keine Szenarien. Fehler in der Geschäftslogik blieben unentdeckt.

Vorteile:

Schnelle Erreichung eines formalen Kriteriums
Motivation, mehr Tests zu schreiben

Nachteile:

Tests erfassen keine echten Bugs
Technische Schulden steigen, das Team verliert das Vertrauen in die Tests

Positiver Fall

Das Team entwickelte eine Abdeckungsstrategie mit Hilfe der Traceability Matrix und risikobasierter Tests: die kritischste Funktionalität wird E2E abgedeckt, weniger wichtige – durch Unit-Tests. Einmal im Monat wird die Abdeckung nach Szenarien überprüft.