Historische Testdaten auswerten: Trends statt Momentaufnahmen

1. Warum eine Momentaufnahme allein nicht ausreicht

Jeder einzelne Testlauf liefert für sich genommen nur ein binäres Ergebnis pro Test, aus dem sich weder ableiten lässt, ob dieses Ergebnis typisch oder ungewöhnlich ist, noch ob sich die Situation im Vergleich zur Vorwoche verbessert oder verschlechtert hat. Ohne eine Vergleichsbasis über die Zeit bleibt jeder einzelne rote Test isoliert und lässt sich nicht einordnen, was insbesondere bei sporadischen, seltenen Fehlschlägen dazu führt, dass echte Muster erst nach langer Zeit oder gar nicht erkannt werden.

Eine systematisch aufgebaute Historie verwandelt diese isolierten Einzelergebnisse in eine durchsuchbare, auswertbare Zeitreihe, aus der sich Fragen beantworten lassen wie: Ist dieser Test schon immer gelegentlich fehlgeschlagen, oder hat das Problem erst vor drei Wochen mit einem bestimmten Commit begonnen? Wächst die Gesamtlaufzeit gleichmäßig über alle Testfälle hinweg, oder verursacht eine einzelne, neu hinzugekommene Testdatei den Großteil des Anstiegs? Ohne belastbare historische Daten bleiben all diese Fragen reine Vermutungen, die im Zweifel mit widersprüchlichen, subjektiven Erinnerungen einzelner Team-Mitglieder beantwortet werden, statt mit nachprüfbaren, aus echten Läufen stammenden Zahlen.

2. Eine geeignete Datenablage für Testergebnisse aufbauen

Die Grundlage jeder historischen Auswertung ist eine strukturierte, dauerhafte Speicherung jedes einzelnen Testlaufs, die über die flüchtige CI-Ausgabe hinausgeht, wofür sich eine einfache, relationale Tabelle mit einer Zeile pro Testfall und Lauf bereits gut eignet, ergänzt um Zeitstempel, Ergebnis, Laufzeit, Branch und Commit-Hash als Mindestangaben.

Für ein Magento-Projekt bietet sich an, diese Daten direkt nach jedem CI-Lauf über einen einfachen Export-Schritt in eine dedizierte Datenbank oder, für einen einfacheren Einstieg, in eine Reihe strukturierter JSON-Dateien in einem eigenen Speicher-Bucket zu schreiben, statt die Rohdaten ausschließlich in den ohnehin nach kurzer Zeit von der CI-Plattform automatisch gelöschten Artefakten vorzuhalten.

CREATE TABLE test_ergebnisse (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    test_name VARCHAR(255) NOT NULL,
    ergebnis ENUM('bestanden', 'fehlgeschlagen', 'übersprungen') NOT NULL,
    laufzeit_ms INT UNSIGNED NOT NULL,
    branch VARCHAR(100) NOT NULL,
    commit_hash CHAR(40) NOT NULL,
    ausgefuehrt_am DATETIME NOT NULL,
    INDEX idx_test_zeit (test_name, ausgefuehrt_am)
);

3. Testlaufzeiten über die Zeit auswerten

Mit einer aufgebauten Historie lässt sich die Entwicklung der Gesamtlaufzeit über Wochen und Monate hinweg als Zeitreihe darstellen, wobei sich neben dem reinen Gesamttrend auch gezielt die Frage beantworten lässt, welche einzelnen Testfälle den größten Beitrag zum Anstieg leisten, indem die durchschnittliche Laufzeit pro Test über denselben Zeitraum verglichen wird.

Diese testfall-spezifische Betrachtung deckt häufig auf, dass eine allgemeine, im Aggregat moderat wirkende Laufzeit-Steigerung tatsächlich auf eine kleine Anzahl einzelner, überproportional langsam gewordener Tests zurückzuführen ist, etwa weil ein bestimmter Test seit einer bestimmten Änderung unnötig lange, feste Wartezeiten statt gezielter Warte-Bedingungen verwendet, was sich gezielt beheben lässt, sobald der verursachende Testfall einmal konkret identifiziert ist.

4. Wiederkehrend flakige Tests anhand der Historie identifizieren

Ein einzelner, isolierter Fehlschlag lässt sich nicht zuverlässig von echter, wiederkehrender Flakiness unterscheiden, wohl aber ein über mehrere Wochen aggregiertes Muster: Ein Test, der über die letzten dreißig Läufe hinweg fünf Mal fehlgeschlagen ist, ohne dass sich der zugrunde liegende Code an diesen Stellen tatsächlich geändert hätte, ist ein klarer Kandidat für eine gezielte Stabilisierung, während ein Test mit einem einzigen, isolierten Fehlschlag in den letzten dreißig Läufen eher auf einen einmaligen, externen Zwischenfall hindeutet.

Ein praktisches Auswertungsmuster ist eine wöchentlich automatisch generierte Rangliste der zehn Tests mit der höchsten Fehlschlagsrate über den vergangenen Monat, die dem Team eine klare, datenbasierte Priorisierung liefert, statt sich bei der Frage, welcher flakige Test als Nächstes stabilisiert werden sollte, auf subjektive, oft von der zuletzt ärgerlichsten Erfahrung geprägte Einschätzungen zu verlassen.

SELECT test_name,
       COUNT(*) AS gesamt_laeufe,
       SUM(CASE WHEN ergebnis = 'fehlgeschlagen' THEN 1 ELSE 0 END) AS fehlschläge,
       ROUND(100.0 * SUM(CASE WHEN ergebnis = 'fehlgeschlagen' THEN 1 ELSE 0 END) / COUNT(*), 2) AS fehlschlagsrate
FROM test_ergebnisse
WHERE ausgefuehrt_am >= NOW() - INTERVAL 30 DAY
GROUP BY test_name
HAVING fehlschläge > 0
ORDER BY fehlschlagsrate DESC
LIMIT 10;

5. Aggregation und sinnvolle Aufbewahrungsdauer

Da die Rohdatenmenge bei hunderten Tests und mehreren täglichen CI-Läufen schnell erheblich wächst, empfiehlt sich eine gestaffelte Aufbewahrungsstrategie: Detaillierte Einzelergebnisse bleiben für einen begrenzten Zeitraum, etwa neunzig Tage, vollständig erhalten, während ältere Daten zu wöchentlichen oder monatlichen Aggregaten (Erfolgsquote, durchschnittliche Laufzeit, Fehlschlagsanzahl) verdichtet und die granularen Einzeleinträge anschließend gelöscht werden.

Diese Staffelung reduziert den Speicherbedarf erheblich, ohne die für langfristige Trend-Analysen tatsächlich benötigte Information zu verlieren, da für eine Frage wie "Ist die Laufzeit in den letzten sechs Monaten gestiegen" ohnehin nur monatliche Durchschnittswerte benötigt werden, nicht jeder einzelne, granulare Datenpunkt der letzten hundertfünfzig Tage. Ein regelmäßig, etwa monatlich, laufender Aggregations-Job, der ältere Rohdaten automatisch verdichtet und archiviert, verhindert dabei, dass diese Wartungsaufgabe in Vergessenheit gerät und die Datenbank stattdessen unkontrolliert weiterwächst.

6. Regelmäßige Team-Reviews auf Basis der Historie

Reine Datensammlung allein erzeugt noch keinen Mehrwert, solange niemand die aufbereiteten Historien-Daten tatsächlich regelmäßig betrachtet und daraus Entscheidungen ableitet, weshalb sich ein kurzer, etwa vierzehntägiger Team-Review-Termin bewährt, in dem gemeinsam die aktuelle Rangliste flakiger Tests, der Laufzeit-Trend und auffällige Veränderungen seit dem letzten Review besprochen werden.

Ein solcher Termin sollte bewusst kurz und ergebnisorientiert gehalten werden, etwa fünfzehn Minuten mit einer klaren Tagesordnung, die konkrete, priorisierte Maßnahmen als Ergebnis produziert, statt in eine unstrukturierte, allgemeine Diskussion über die Testqualität abzudriften, deren Erkenntnisse anschließend ohne konkrete Zuordnung an eine verantwortliche Person folgenlos verpuffen.

7. Statistische Anomalie-Erkennung jenseits reiner Fehlschläge

Nicht jedes relevante Signal äußert sich als tatsächlicher Testfehlschlag: Ein Test, der weiterhin zuverlässig grün durchläuft, dessen Laufzeit sich aber innerhalb weniger Läufe plötzlich verdoppelt hat, deutet häufig auf ein sich anbahnendes Backend-Problem hin, etwa eine fehlende Datenbank-Indexierung nach einer kürzlichen Migration, lange bevor dieses Problem tatsächlich zu einem sichtbaren Fehlschlag oder gar einem Produktionsvorfall eskaliert.

Eine mit der historischen Datenablage kombinierte, einfache statistische Anomalie-Erkennung, etwa über den gleitenden Durchschnitt und die Standardabweichung der Laufzeit eines Tests über die letzten dreißig Läufe, kann solche Ausreißer automatisch markieren, ohne dass ein Mensch das Laufzeit-Diagramm jedes einzelnen Tests manuell durchsehen müsste. Überschreitet die aktuelle Laufzeit eines Tests etwa das Dreifache der Standardabweichung gegenüber dem historischen Mittelwert, lässt sich daraus automatisch ein niedrigschwelliger, informativer Hinweis statt eines vollwertigen, dringlichen Alarms generieren, der dem Team frühzeitig einen Hinweis liefert, ohne die im vorherigen Artikel beschriebene Alert-Fatigue durch übertriebene Dringlichkeit zu riskieren.

8. Visualisierung als Brücke zwischen Rohdaten und Entscheidung

Rohe Tabellen mit historischen Testdaten sind zwar vollständig, aber für eine schnelle, intuitive Einordnung ungeeignet, weshalb sich eine einfache Dashboard-Visualisierung lohnt, etwa ein Liniendiagramm für den Laufzeit-Trend über die letzten sechs Monate und ein Balkendiagramm für die zehn Tests mit der höchsten aktuellen Fehlschlagsrate, kombiniert in einem einzigen, auf einen Blick erfassbaren Überblick.

Werkzeuge wie Grafana, das direkt an dieselbe relationale Datenbank angebunden werden kann, eignen sich hierfür gut, da sie automatisch aktualisierte Dashboards ohne wiederholten manuellen Export-Aufwand ermöglichen und sich zusätzlich mit denselben, bereits für andere Zwecke betriebenen Observability-Werkzeugen des Teams kombinieren lassen, statt eine völlig separate, isolierte Visualisierungslösung ausschließlich für Testdaten zu betreiben.

9. Bausteine der historischen Testauswertung im Überblick

Die folgende Tabelle fasst die vorgestellten Bausteine zusammen.

10. Zusammenfassung

11. FAQ: Historische Testdaten: Das Wichtigste auf einen Blick