Testmetriken sind Kennzahlen, die aus den Rohdaten der Testwerkzeuge abgeleitet werden und zeigen, was die Testautomatisierung einem Projekt einbringt. Ein selbst entwickelter Metric Collector sammelt dafür täglich Daten aus Jira, GitLab und Jenkins, historisiert sie und speist ein Power-BI-Dashboard, das Testkoordinatoren und Management in getrennten Ansichten lesen.
Das Wichtigste in Kürze
- Testmetriken gewinnen ihren Wert aus der Historie: Erst der Verlauf über Wochen zeigt, ob offene Tests und Fehlerzahl vor dem Release wirklich sinken.
- Ivaylo Brüssow hält die reine Zahl automatisierter Testfälle für irrelevant; die Frage ist, was das Projekt mit der Automatisierung gewinnt.
- Ein selbst geschriebener Metric Collector in Python läuft jeden Abend auf Jenkins und zieht Daten aus Jira, Xray, zwei GitLab-Instanzen, SonarQube und Dependency-Track.
- Liegen in Git mehr Testskripte als in Jenkins laufen oder fehlen die Tests in Jira, zeigt das Dashboard eine Lücke, und das Team spricht die Anwendung direkt an.
- Acht gewichtete Metriken ergeben je Anwendung einen Score von 0 bis 5 nach dem Muster des Nutri-Scores, den die Führungsebene einmal im Monat per Mail bekommt.
Metriken für die Testautomatisierung: Testfälle zählen reicht nicht
Rund 100 Anwendungen machen bei dem Vorhaben mit, an dem Ivaylo Brüssow und Andrej Nod arbeiten, und für jede davon will irgendwer wissen, wo die Testautomatisierung steht. In den Pilotprojekten kamen die Metriken dafür noch aus der Hand: Testfälle zählen, Schlüsselwörter im Robot Framework zählen, in eine Tabelle tippen. Bei 100 Anwendungen trägt das nicht mehr, und die Zahl der automatisierten Testfälle sagt ohnehin wenig darüber, was die Automatisierung bringt. Deshalb führt bei ihnen ein selbst entwickelter Metric Collector die Daten aus Jira, GitLab und Jenkins in einem Power-BI-Dashboard zusammen und zeigt die Wirksamkeit der Testautomatisierung über Metriken, die historisiert sind und eine Formel haben.
Der Druck dazu kam aus zwei Richtungen. Während eines Fusionsprogramms bot das Team Testautomatisierung als Dienstleistung an und musste dem oberen Management belegen, was aus den bereitgestellten Mitteln geworden ist. Und intern wollte das Team selbst wissen, warum in manchen Bereichen die Logs eine gerade Linie zeigen: Testfälle liegen da, aber nichts läuft mehr. Braucht der Bereich Unterstützung, oder hat sich der Fokus verschoben?
„Es ist irrelevant, wie viele Testfälle ich als reine Zahl automatisiert habe. Die Frage ist, was gewinne ich damit?“
(Ivaylo Brüssow)
Das Team hat deshalb zuerst geklärt, welche Daten es selbst in der Hand hat und welche Metriken sich daraus ableiten lassen. Jede Metrik ist dokumentiert: Wer einen Wert im Dashboard sieht, sieht auch die Formel dahinter. Steht ein Koeffizient deutlich unter 1, soll der Anwendungsverantwortliche selbst ableiten können, wie er auf die 1 kommt.
Welche Metriken zeigen die Wirksamkeit besser als die Zahl der Testfälle?
Die erste Metrik, die eingefordert wurde, war Codeabdeckung. Ivaylo musste absagen: Ohne zusätzliche Werkzeuge in den einzelnen Projekten lässt sie sich zentral nicht messen. Angeboten hat das Team stattdessen zwei Metriken, die aus den vorhandenen Systemen kommen und zur Hauptmetrik geworden sind.
| Metrik | Was das Team damit misst | Aus den vorhandenen Systemen messbar |
|---|---|---|
| Codeabdeckung | Die zuerst eingeforderte Metrik | Nein, nur mit zusätzlichen Werkzeugen je Projekt |
| Testabdeckung | Ob jede Änderung und jede Jira-Story mit mindestens einem Testfall nachvollziehbar abgedeckt ist | Ja, aus Jira mit Xray |
| Automatisierungsgrad | Anteil der automatisierten Tests an der Gesamtsumme aller Tests | Ja, aus Jira, GitLab und Jenkins |
Erst nebeneinander sagen die zwei Metriken etwas: Eine Anwendung hat viele Testskripte im Git-Repository, aber kaum Testfälle in Jira, und der Automatisierungsgrad fällt schlecht aus, obwohl automatisiert wurde. Andrej geht mit so einem Befund in die Anwendung und bittet darum, die Daten einzupflegen, denn gezählt wird aus den Quellen, die alle nutzen. Die Antwort „ihr zählt falsch“ kam vor; beim Nachsehen fehlten die Daten oder lagen im falschen Format. Die Metrik prüft so nebenbei, ob der Prozess eingehalten wird, und zwar täglich und ohne dass jemand alle paar Monate ein Audit zusammenträgt.
Wie kommen Daten aus Jira, GitLab und Jenkins auf ein Dashboard?
An Daten fehlte es nie, sie lagen nur verteilt. Jira liefert seinen Tagesabzug, Jenkins seinen, GitLab seinen, und jedes Werkzeug kennt nur den eigenen Bereich. Das Team wollte die Zahlen aus allen Systemen auf einer Kachel, übereinandergelegt und mit Zeitstempel. Dafür hat es den Metric Collector geschrieben, den Namen inklusive: eine Python-Software, die täglich spätabends auf Jenkins startet, wenn die Jira-Tickets des Tages geschlossen und alle Pipelines gelaufen sind.
Angebunden sind Jira mit Xray, zwei GitLab-Instanzen, die Jenkins-Instanzen und OpenShift-Pipelines, dazu SonarQube und Dependency-Track. Je Metrik gibt es einen Worker, der seine Daten aufbereitet und historisiert ablegt. Die Berichte von Jira baut niemand nach; der Collector zieht nur die Zahlen, die er braucht, und bringt sie auf einen gemeinsamen Nenner.
Der größte Teil der Arbeit steckt im Mapping. Dieselbe Anwendung heißt in Git anders als in Jira und wieder anders in Jenkins. Daraus ist eine große Mapping-Tabelle entstanden, an manchen Stellen ergänzt um automatische Verfahren: Jira liefert alle Anwendungen, die an einem Release teilnehmen, samt Release-Inhalten; darüber legt der Collector die Testabdeckung, die Ausführungen auf Jenkins und die Zahl der Testskripte in Git. Erst in dieser Überlagerung werden Lücken sichtbar. Skripte, die im Repository liegen, aber auf keinem Jenkins laufen. Eine Kurve, die einmal nach oben ging und dann eingeschlafen ist.
Was zeigen historisierte Metriken vor dem Release?
Ein aktuelles Bild liefert Jira auch. Was Jira nicht liefert, ist die Entwicklung: Wie sah es zu Beginn der Testphase aus, wie sieht es kurz vor dem Release aus? Die Erwartung ist klar. Die Kurve der noch abzuarbeitenden Tests geht nach unten, die Zahl der Fehler ebenfalls. Tut sie das nicht, sieht man es Wochen vorher. Andrej nennt das den „Unfall in Zeitlupe“: Der Release läuft gegen die Wand, und der Verlauf zeigt es, lange bevor der Termin da ist. Umgekehrt erlaubt ein positiver Trend, mit gutem Gewissen zu releasen, weil Abdeckung und Testzeit zusammenpassen. Das ist objektiver als die Ampel, die jemand vor dem Steering Committee in PowerPoint wieder auf Grün stellt.
Für die Releaseplanung gibt es die „Release-Klammer“: einen Filter, der alles ausblendet, was für den konkreten Release nicht zählt. Dazu kommt ein zweiter Effekt der Historie. Der Collector sammelt mehr Daten ein, als das Dashboard heute auswertet. Kommt in einem Jahr jemand mit einer neuen Metrik, liegt die Datenbasis seit Monaten da und muss nur noch definiert und visualisiert werden.
Ein Score aus acht Metriken für das Management, die Details für Testkoordinatoren
Wer was sieht, hängt von der Rolle ab, und die Zielgruppen hat das Team im Workshop festgelegt. Ein Manager will einen groben Überblick. Dafür aggregiert das Dashboard mehrere Metriken zu einem Score von 0 bis 5, ähnlich einem Nutri-Score mit grünem und rotem Bereich. Acht Metriken fließen unterschiedlich gewichtet ein. Wer seinen Score verbessern will, muss mehr ändern als eine Zahl; das ist Absicht. Einmal im Monat geht der Score automatisch per Mail an die obere Führungsebene: Wo stehen wir, welche Projekte liegen vorn, wo ist der beste Score erreicht.
Der Testkoordinator bekommt eine eigene Ansicht mit vorgefertigten Filtern und denselben Daten in mehr Tiefe. Wer noch weiter will, geht in die Werkzeuge selbst: SonarQube, Jira, Git. Die Daten sind auf allen Ebenen dieselben, nur anders gefiltert und zusammengesetzt. Visualisiert wird das Ganze in Power BI, weil es im Konzern schon im Einsatz war; eine Kollegin aus dem Team hat das Dashboard mit Filtern, Ansichten und teilweise rollenbezogenen Sichten gebaut.
Workshops mit den Fachbereichen entscheiden über die Akzeptanz
Die Metriken sind in drei Runden entstanden. Vor dem Projekt gab es Workshops zu der Frage, wie gut oder schlecht die Automatisierung läuft und welche Handvoll Metriken dazu etwas sagt. Nach dem Proof of Concept des Metric Collectors einigte sich das Team intern auf die Metriken, die der Collector füttern soll. Und als der erste Prototyp lief, kamen Vertreter aus den Fachbereichen dazu, vom Entwickler über den Testleiter bis zum Abteilungsleiter, und diskutierten mehrere Stunden. Die Botschaft des Teams: Wir haben das Instrument, es kann das und das liefern, sagt uns, was ihr braucht, denn wir bauen es für euch.
Das Feedback nennt Ivaylo durchwachsen. Das Dashboard findet Akzeptanz, das Team wünscht sich mehr davon und deutlich mehr Einsatz. Manche Anforderungen stoßen an die Grenzen von Power BI, dann heißt es abwägen, ob man darum herum baut oder einen anderen Weg geht. Fertig ist das Vorhaben nach anderthalb Jahren nicht. Aber das Bauchgefühl ist raus. Aus „wir haben so viel, schätze ich“ ist „wir haben genau so viel“ geworden, und die Formel dahinter steht daneben.
