In vielen Projekten ist die Antwort auf die Frage nach dem Teststand eine Zahl: so und so viele Testfälle, so und so viele davon automatisiert. Diese Zahl lässt sich leicht erheben und wirkt in Statusberichten beruhigend. Über die tatsächliche Verlässlichkeit der Software sagt sie allerdings wenig aus. Genau an diesem Punkt setzt eine aktuelle Diskussion im Testing-Umfeld an: Richard Seidl hat mit Ivaylo Brüssow und Andrej Nod über einen Metric Collector gesprochen – ein Werkzeug, das Kennzahlen zur Testautomatisierung erhebt und das Ergebnis als Score bewertet.

Der Grundgedanke ist einfach formuliert, in der Praxis aber unbequem: Wer Testfälle zählt, misst Aufwand. Wer Metriken erhebt, misst Wirkung. Der Unterschied wird dort relevant, wo Teams wissen müssen, ob sie ihrer Testautomatisierung im Ernstfall vertrauen können.

Warum die Testfallzahl in die Irre führt

Eine hohe Testfallzahl kann drei sehr verschiedene Dinge bedeuten. Sie kann für eine gut durchdachte Abdeckung stehen. Sie kann aber auch das Ergebnis von Redundanz sein, bei der dieselbe Logik in leicht abgewandelter Form immer wieder geprüft wird. Und sie kann schlicht Altlast sein: Tests, die niemand mehr pflegt, die regelmäßig rot werden und deren Fehlschläge das Team aus Gewohnheit ignoriert.

Aus der reinen Anzahl lässt sich keiner dieser drei Fälle unterscheiden. Für Entscheiderinnen und Entscheider heißt das: Eine Kennzahl, die in allen drei Szenarien identisch aussieht, taugt nicht als Steuerungsgröße. Sie suggeriert Kontrolle, ohne sie zu liefern.

Was ein Metric Collector leisten soll

Ein Metric Collector – also eine Komponente, die Messwerte automatisiert aus Repositories, Testläufen und Build-Pipelines einsammelt – verfolgt einen anderen Ansatz. Statt einer einzelnen Zahl entsteht ein Bündel von Kennzahlen, das anschließend zu einer Bewertung verdichtet wird. Der Score ist dabei kein Selbstzweck, sondern ein Kommunikationsmittel: Er macht den Zustand der Testautomatisierung über Teams und Projekte hinweg vergleichbar und zeigt Veränderungen über die Zeit.

Entscheidend ist die Automatisierung der Erhebung selbst. Kennzahlen, die jemand manuell in einer Tabelle pflegen muss, veralten schnell und werden irgendwann nicht mehr gepflegt. Werte, die bei jedem Build ohnehin anfallen, stehen dagegen dauerhaft und ohne zusätzlichen Aufwand zur Verfügung.

Worauf es bei Kennzahlen praktisch ankommt

Welche Größen konkret sinnvoll sind, hängt vom Projekt ab. Aus der Projektpraxis haben sich jedoch einige Leitplanken bewährt, wenn Teams von der Zählweise auf eine Bewertung umstellen:

  • Stabilität vor Menge. Tests, die sporadisch ohne Codeänderung fehlschlagen, untergraben das Vertrauen in die gesamte Suite. Ihre Häufigkeit ist eine aussagekräftigere Größe als die Gesamtzahl.
  • Laufzeit und Rückmeldedauer. Eine Testsuite, deren Ergebnis erst nach Stunden vorliegt, verändert das Verhalten im Team – Änderungen werden gebündelt, Fehlerursachen schwerer zuzuordnen.
  • Verteilung über die Teststufen. Ob der Schwerpunkt auf schnellen Unit-Tests oder auf langsamen, wartungsintensiven Oberflächentests liegt, beeinflusst Kosten und Aussagekraft erheblich.
  • Abdeckung der fachlich kritischen Pfade. Nicht jede Codezeile ist gleich wichtig. Interessant ist, ob die geschäftskritischen Abläufe abgesichert sind.
  • Pflegezustand. Deaktivierte oder dauerhaft übersprungene Tests sind ein Warnsignal, das in reinen Zählungen vollständig untergeht.

Ein Score fasst solche Dimensionen zusammen. Er ersetzt die fachliche Diskussion nicht, er strukturiert sie: Fällt der Wert, lässt sich gezielt nachsehen, welche Dimension sich verschlechtert hat.

Der Zusammenhang mit KI-gestützter Entwicklung

Die Frage nach belastbaren Testmetriken gewinnt an Gewicht, weil Code zunehmend mit Unterstützung von Sprachmodellen entsteht. Generierter Code lässt sich sehr schnell produzieren – einschließlich generierter Tests. Damit verschiebt sich der Engpass: Nicht das Schreiben von Tests ist die knappe Ressource, sondern die Beurteilung, ob diese Tests tatsächlich etwas absichern.

Wenn Menge kaum noch Aufwand kostet, verliert Menge endgültig ihre Aussagekraft als Qualitätsindikator. Eine Suite kann binnen kurzer Zeit auf mehrere hundert Testfälle anwachsen, ohne dass ein einziger zusätzlicher Fehler gefunden würde. Objektive Kennzahlen sind in dieser Lage kein Luxus, sondern die Voraussetzung dafür, überhaupt eine Aussage über Verlässlichkeit treffen zu können.

Was Metriken nicht leisten

Bei aller Nützlichkeit gilt eine Einschränkung, die Teams früh einplanen sollten: Sobald eine Kennzahl zum Ziel wird, lässt sie sich optimieren, ohne dass sich die Qualität verbessert. Eine Abdeckungsquote lässt sich mit Tests ohne sinnvolle Zusicherungen heben. Flaky Tests lassen sich entfernen, indem man sie deaktiviert statt repariert.

Ein Score sollte deshalb als Indikator verstanden werden, der Gespräche auslöst – nicht als Zielvorgabe, an der Teams gemessen werden. Der Nutzen liegt in der Entwicklung über die Zeit und im Vergleich zwischen Systemen, weniger im absoluten Wert eines einzelnen Monats.

Einstieg ohne großes Programm

Ein Umstieg auf metrikbasierte Bewertung muss nicht als Initiative mit eigenem Projektbudget beginnen. In der Regel reicht ein pragmatischer Einstieg: eine Handvoll Kennzahlen definieren, deren Erhebung automatisiert in die bestehende Pipeline einbauen und die Werte über einige Releases hinweg beobachten. Erst wenn die Datenbasis stabil ist, lohnt sich die Verdichtung zu einem Score.

Wichtig ist, dass die Kennzahlen aus derselben Quelle stammen wie die Builds selbst. Nur dann sind sie manipulationsarm und bleiben aktuell, auch wenn im Projektalltag gerade anderes dringender ist.

Einordnung für die Projektpraxis

Für Web- und Softwareprojekte verschiebt sich die relevante Frage in Statusrunden: Nicht mehr wie viele Tests existieren, sondern wie stabil, wie schnell und wie zielgerichtet sie sind. Wer diese Größen automatisiert erhebt, bekommt eine Diskussionsgrundlage, die über Teamgrenzen hinweg trägt und Investitionen in Qualitätssicherung nachvollziehbar macht. Gerade dort, wo KI-Werkzeuge die Codeproduktion beschleunigen, entscheidet die Aussagekraft der Testbasis darüber, ob dieses Tempo in verlässliche Releases mündet oder in zusätzliche Nacharbeit.

Quellen