Testmetriken und Reporting in der Testautomatisierung

Coverage, Flaky-Rate, Laufzeit: In mehreren unserer bisherigen Artikel tauchen Testmetriken als Randthema auf, etwa als Kennzahl im Sprint-Dashboard oder als Symptom für instabile Testdaten. Dieser Beitrag behandelt das Thema eigenständig und vertiefend: Welche Kennzahlen gibt es, was sagen sie tatsächlich aus, und wie lässt sich daraus ein Reporting bauen, das im Team auch wirklich genutzt wird? Wie schon bei den Testfall-Generierungsverfahren gilt: Keine einzelne Kennzahl liefert das vollständige Bild. Aussagekräftig wird das Reporting erst durch die richtige Kombination.

Testabdeckung (Code Coverage)

Die Testabdeckung gibt an, welcher Anteil des Codes bei der Testausführung durchlaufen wird. Am häufigsten wird sie als Statement Coverage (welche Zeilen wurden ausgeführt), Branch Coverage (welche Verzweigungen) oder Path Coverage (welche Kombinationen von Verzweigungen) gemessen. Ein Modul mit 200 Codezeilen, von denen 160 durch Tests ausgeführt werden, erreicht etwa eine Statement Coverage von 80 %; Tools wie JaCoCo (Java) oder Coverage.py (Python) berechnen das automatisch bei jedem CI-Lauf (CI steht für Continuous Integration, also die automatisierte Zusammenführung und Prüfung von Codeänderungen) und markieren ungetestete Zeilen farblich im Bericht.

Damit lassen sich ungetestete Codebereiche identifizieren, ein Mindestwert als Gate in der CI/CD-Pipeline definieren (CD steht für Continuous Delivery bzw. Deployment, also die automatisierte Bereitstellung dieser Änderungen in einer Test- oder Produktionsumgebung) oder neue Tests gezielt auf schwach abgedeckte Stellen ausrichten. Die Kennzahl ist objektiv messbar und leicht zu automatisieren, sagt aber nichts über die Qualität der Prüfung aus: Code kann durchlaufen werden, ohne dass ein Ergebnis tatsächlich verifiziert wird.

Deshalb täuscht eine hohe Coverage leicht eine Sicherheit vor, die nicht existiert. Ein Test ohne aussagekräftige Assertion (siehe „Falsche Assertion“ und „Fehlende Assertion“ in unserem Artikel zu typischen Fehlern in der Testautomatisierung) erhöht die Zahl, ohne einen einzigen Fehler zu finden. Wird Coverage selbst zum Ziel, schreiben Teams Tests, um die Zahl zu steigern, statt um Fehler zu finden.

Anforderungsabdeckung (Requirements Coverage)

Die Anforderungsabdeckung setzt die Anzahl der Anforderungen bzw. Akzeptanzkriterien, die durch mindestens einen Testfall abgedeckt sind, ins Verhältnis zur Gesamtzahl der Anforderungen. Nachverfolgt wird das meist über eine Traceability-Matrix im Testmanagement-Tool. Sind von 40 Akzeptanzkriterien eines Release beispielsweise 35 mit mindestens einem Testfall verknüpft, ergibt das eine Anforderungsabdeckung von 87,5 %, sichtbar etwa als Traceability-Matrix in Xray oder TestRail.

Diese Kennzahl bildet eine Grundlage für Release-Freigabe-Entscheidungen, dient dem Nachweis regulatorischer Anforderungen etwa in Medizintechnik oder Automotive und macht fachlich ungetestete Bereiche sichtbar. Sie liefert damit eine fachliche statt rein technische Sicht auf die Testabdeckung und eignet sich gut für Audits, verursacht aber manuellen Zusatzaufwand, weil die Verknüpfung zwischen Anforderung und Testfall gepflegt werden muss.

Zudem sagt eine als „abgedeckt“ markierte Anforderung nichts über die Tiefe des zugehörigen Tests aus: Ein einzelner oberflächlicher Test genügt formal, obwohl wichtige Randfälle ungetestet bleiben.

Pass-Rate (Erfolgsquote)

Die Pass-Rate beschreibt den Anteil der erfolgreich durchlaufenen Testfälle an der Gesamtzahl der in einem Lauf ausgeführten Tests. Bestehen von 500 ausgeführten Regressionstests beispielsweise 485, ergibt das für diesen CI-Lauf eine Pass-Rate von 97 %.

Sie liefert eine schnelle Gesamteinschätzung der Stabilität eines Builds und dient als Entscheidungsgrundlage für Deployment-Gates, etwa eine Freigabe erst ab einer definierten Schwelle. Der Vorteil liegt in der einfachen Berechnung und Kommunikation im Team, der Nachteil ist, dass sie nichts darüber aussagt, welche Tests fehlschlagen: Eine kritische Kernfunktion zählt gleich viel wie ein Randfall.

Problematisch wird die Kennzahl vor allem in Kombination mit einer hohen Flaky-Rate: Ein Teil der „erfolgreichen“ Tests wird dann nicht durch stabile Funktionalität grün, sondern durch Zufall oder Auto-Retry-Mechanismen, die Instabilität verschleiern.

Flaky-Rate

Die Flaky-Rate misst den Anteil der Tests, die bei unveränderter Codebasis und unveränderten Testdaten mal erfolgreich, mal fehlschlagend sind. Erfasst wird das etwa über mehrere Wiederholungsläufe oder historische CI-Daten. Wird ein Test über 20 identische CI-Läufe beobachtet und schlägt er in 3 davon ohne erkennbaren funktionalen Grund fehl, ergibt das eine Flaky-Rate von 15 % für diesen Test.

Die Kennzahl hilft, Wartungsarbeit an der Testsuite zu priorisieren, und wirkt als Frühwarnindikator für instabile Testinfrastruktur oder Testdaten. Sie macht damit ein sonst schwer greifbares Problem messbar, erfordert dafür aber wiederholte Ausführungen oder historische Daten und damit zusätzlichen Mess-Overhead.

Ihr Nutzen verpufft allerdings, wenn sie zwar gemessen, aber ohne Konsequenz beobachtet wird: Bekannt instabile Tests bleiben dann unbehoben, und das Team verliert nach und nach das Vertrauen in die gesamte Suite.

Testlaufzeit (Suite Execution Time)

Die Testlaufzeit gibt an, wie lange eine Testsuite oder ein einzelner Testlauf von Start bis Ende benötigt, meist getrennt nach Testebene wie Unit, Integration oder End-to-End gemessen. Die Unit-Test-Suite läuft etwa in 2 Minuten, die End-to-End-Suite in 45 Minuten. Steigt diese Laufzeit über mehrere Sprints hinweg kontinuierlich an, deutet das auf wachsende technische Schuld in der Testautomatisierung hin.

Die Kennzahl dient der Kapazitätsplanung der CI-Pipeline, als Entscheidungsgrundlage für Parallelisierung oder eine bessere Verteilung über die Testebenen sowie zur Trendbeobachtung, um Verfall früh zu erkennen. Sie ist direkt messbar und wirkt sich unmittelbar auf die Feedback-Geschwindigkeit im Team aus, ist allein betrachtet (etwa ohne Bezug zur Anzahl der Tests) aber wenig aussagekräftig.

Der Druck, die Laufzeit kurz zu halten, kann zudem dazu verleiten, Wartezeiten unsauber zu verkürzen oder Tests zu überspringen, statt die eigentliche Ursache zu beheben, etwa eine fehlende Testpyramide mit zu vielen End-to-End-Tests.

Fehlerdichte (Defect Density)

Die Fehlerdichte setzt die Anzahl gefundener Fehler ins Verhältnis zu einer Bezugsgröße, meist Codeumfang (etwa Fehler pro 1.000 Zeilen Code) oder zu einem Feature bzw. einer Story. Werden in einem Release mit 10.000 neuen Codezeilen 25 Fehler gefunden, ergibt das eine Fehlerdichte von 2,5 Fehlern pro 1.000 Zeilen Code.

Die Kennzahl erlaubt den Vergleich der Qualität unterschiedlicher Komponenten oder Releases über die Zeit und hilft, besonders fehleranfällige Module als Kandidaten für Refactoring oder zusätzliche Tests zu identifizieren. Sie liefert eine über unterschiedlich große Codebasen hinweg vergleichbare, normalisierte Zahl, wobei Codezeilen als Bezugsgröße unscharf bleiben, da unterschiedliche Sprachen und Stile für dieselbe Funktionalität unterschiedlich viele Zeilen erzeugen.

Wird sie zur Leistungsbeurteilung einzelner Personen statt zur Prozessverbesserung verwendet, entsteht zudem ein Anreiz, weniger Fehler zu melden oder sie anders zu kategorisieren. Die Zahl verliert dadurch ihre Aussagekraft.

Defect Escape Rate (Entweichrate)

Die Defect Escape Rate beschreibt den Anteil der Fehler, die trotz Testens erst in Produktion beziehungsweise einer späteren Phase entdeckt werden, im Verhältnis zu allen im gesamten Zyklus gefundenen Fehlern. Werden von 50 im gesamten Release-Zyklus gefundenen Fehlern beispielsweise 45 vor dem Release entdeckt und 5 erst danach in Produktion, ergibt das eine Entweichrate von 10 %.

Sie bewertet die Wirksamkeit der gesamten Teststrategie über alle Testebenen hinweg, nicht nur einer einzelnen Suite, und misst damit den tatsächlichen geschäftlichen Effekt statt reiner Testaktivität. Das Feedback kommt allerdings verzögert, da Produktionsfehler erst nach dem Release sichtbar werden.

Eine niedrige Entweichrate kann außerdem schlicht bedeuten, dass in Produktion wenig genutzte Funktionen betroffen waren, statt dass die Tests besonders wirksam waren. Ohne Kontext zu Nutzungsintensität und Schweregrad ist die Kennzahl allein wenig aussagekräftig.

Mutationstest-Score (Test Effectiveness)

Der Mutationstest-Score misst, wie gut eine Testsuite tatsächlich Fehler erkennt: Ein Werkzeug baut gezielt kleine, künstliche Fehler, sogenannte Mutationen, in den Code ein, und der Score gibt an, welcher Anteil davon von der Testsuite erkannt bzw. „getötet“ wird. Ändert etwa ein Mutationstest-Tool wie PIT (Java) oder mutmut (Python) automatisiert einen Vergleichsoperator von > zu >= in einer Funktion und schlägt danach kein einziger Test fehl, wurde diese Mutation nicht erkannt, und der Score sinkt entsprechend.

Die Kennzahl prüft die tatsächliche Aussagekraft einer Testsuite jenseits reiner Code Coverage und deckt gezielt schwache Assertions auf, genau das, was Code Coverage verschleiert: Tests, die Code ausführen, aber nichts wirklich prüfen.

Sie ist dafür rechenintensiv, da für jede Mutation die gesamte Suite erneut laufen muss, weshalb sie bei großen Codebasen oft nur auf Teilbereiche angewendet wird. Ein niedriger Score zeigt zudem zwar schwache Tests auf, aber nicht automatisch, welche davon fachlich relevant sind. Eine manuelle Bewertung der Ergebnisse bleibt notwendig.

Reporting: Kennzahlen sichtbar und wirksam machen

Trends statt Momentaufnahmen

Ein einzelner Messwert sagt wenig aus, erst der Verlauf über die Zeit macht eine Kennzahl handlungsrelevant. Eine Flaky-Rate von 5 % ist unauffällig, wenn sie seit Monaten stabil ist, aber ein Warnsignal, wenn sie in drei Sprints von 1 % auf 5 % gestiegen ist. Dashboards sollten daher grundsätzlich Zeitreihen zeigen, nicht nur den aktuellen Stand.

Zielgruppengerechte Aufbereitung

Ein Entwicklungsteam braucht andere Details als das Management: welcher konkrete Test flaky ist und welche Codezeile nicht abgedeckt ist, versus den Trend der Entweichrate über mehrere Releases hinweg. Ein einziges Dashboard für beide Zielgruppen führt in der Praxis meist dazu, dass es für keine der beiden wirklich nützlich ist.

Automatisiertes statt manuelles Reporting 

Kennzahlen, die manuell zusammengetragen werden müssen, veralten schnell und werden im Alltag nicht gepflegt. Erst eine Anbindung an CI/CD-Pipeline und Testmanagement-Tools, die Kennzahlen automatisch aktualisiert, ist die Voraussetzung dafür, dass ein Reporting im Team tatsächlich genutzt wird.

Von der Kennzahl zur Ursache: Fehleranalyse

Eine Kennzahl wie Fehlerdichte oder Defect Escape Rate zeigt, dass und wo Fehler auftreten, nicht warum. Erst eine systematische Fehleranalyse, die gefundene Fehler nach Ursache kategorisiert (z. B. Anforderung, Design, Code, Testumgebung oder Testdaten), macht aus der reinen Zahl eine Handlungsgrundlage: Häufen sich Fehler in einer bestimmten Kategorie oder Komponente, lässt sich die nächste Verbesserung gezielt dort ansetzen, statt pauschal mehr zu testen.

Fallstricke: Goodhart's Law und Vanity Metrics

Wird eine Kennzahl selbst zum Ziel, etwa eine Coverage-Quote als Bonuskriterium, verliert sie ihre Aussagekraft, weil Teams beginnen, gezielt auf die Zahl statt auf das dahinterliegende Ziel zu optimieren (Goodhart's Law: Sobald ein Maß zum Ziel wird, taugt es nicht mehr als Maß). Ebenso sollten Kennzahlen vermieden werden, die zwar gut aussehen, aber keine Entscheidung beeinflussen, etwa die reine Anzahl automatisierter Testfälle ohne Bezug zu deren Aussagekraft.

Fazit

Keine der vorgestellten Kennzahlen liefert für sich allein ein vollständiges Bild. Coverage und Mutationstest-Score sagen etwas über die Testsuite selbst aus, Pass-Rate und Flaky-Rate über deren Stabilität im Betrieb, Fehlerdichte und Entweichrate über die Wirksamkeit der gesamten Teststrategie. Aussagekräftig wird ein Reporting erst durch die Kombination mehrerer dieser Perspektiven.

Genauso wichtig wie die Auswahl der Kennzahlen ist, wie damit umgegangen wird: als Trend statt Momentaufnahme, zielgruppengerecht aufbereitet und automatisiert statt manuell gepflegt. Werden Kennzahlen stattdessen zum Selbstzweck oder zur Leistungsbeurteilung einzelner Personen, verlieren sie genau die Aussagekraft, für die sie eigentlich eingeführt wurden.

Die systematische Fehleranalyse selbst, von der Kategorisierung nach Ursache bis zu konkreten Methoden wie Root-Cause-Analyse, behandeln wir vertieft in einem der nächsten Artikel dieser Serie.

Sie möchten wissen, welche Kennzahlen für Ihre Testautomatisierung wirklich aussagekräftig sind und wie sich daraus ein Reporting aufbauen lässt, das im Team auch genutzt wird? In einem unverbindlichen Austausch schauen wir uns das gemeinsam an.

Kontaktieren Sie uns unter: office@gruener-it.at