Fußballanalyse trifft Softwaretest

Process Mining für Regressionstests bedeutet: Produktionsdaten zeigen, welche Software-Workflows wie oft tatsächlich durchlaufen werden. Daraus lassen sich gezielt Testfälle ableiten, statt auf Annahmen zu vertrauen. Wer die häufigsten Durchläufe kennt, kann Testabdeckung datenbasiert begründen und Regressionstests auf das Wesentliche konzentrieren.

Das Wichtigste in Kürze

• Process Mining macht sichtbar, welche Workflows in der Produktion tatsächlich durchlaufen werden, und liefert damit eine datenbasierte Grundlage für die Auswahl von Regressionstestfällen statt Bauchgefühl.
• Ein einzelner Workflow kann über 600 verschiedene Durchläufe haben, aber die Top 10 decken bereits rund 80 Prozent aller Produktionsdurchläufe ab.
• Workflows, die in der Produktion häufig auftreten, im Testbetrieb aber überhaupt nicht abgedeckt sind, zeigen konkrete Risikolücken, die ohne Produktionsdatenanalyse unsichtbar bleiben.
• Manuelle Auswertung von Produktionsdaten verliert ihren Wert, sobald die Person, die sie durchführt, das Projekt verlässt. Nur Automatisierung sichert die Nachhaltigkeit des Ansatzes.

Testabdeckung beginnt mit der Frage nach dem Nenner

Wer behauptet, eine Testabdeckung sei zu gering, muss zuerst klären, worauf sich diese Aussage bezieht. Testabdeckung ist im Kern eine Prozentrechnung: Zähler durch Nenner. Ohne definierten Nenner bleibt jedes Urteil über “zu wenig” oder “genug” eine Meinung.

Genau an dieser Stelle setzt der Ansatz von Sven Braxein an. In einem Projekt, das eine langlebige Altsoftware durch ein neues System ablöst, kam der Vorwurf, die Abdeckung im Regressionstest sei zu schlecht. Seine erste Gegenfrage lautete: Was genau ist der Nenner, an dem du das misst?

Diese Frage ist mehr als rhetorisch. Sie zwingt ein Team, die Bezugsgröße offenzulegen, gegen die getestet wird. Erst wenn klar ist, was vollständig abgedeckt sein müsste, lässt sich beziffern, wie viel davon tatsächlich getestet ist.

Was Process Mining sichtbar macht

Process Mining verbindet klassische Prozessanalyse mit Data Mining und zeigt, wie Prozesse in der Produktion wirklich ablaufen. Nicht das gezeichnete Soll-Diagramm, sondern das gelebte Ist.

Jeder Klick, jede Aktion in einem digitalen System hinterlässt eine Spur. Ein Process-Mining-Tool sammelt diese Spuren ein und bringt sie in Beziehung. Das Ergebnis: eine Sicht darauf, was im System real passiert ist, statt einer Annahme darüber, was passieren sollte.

Die Technologie gibt es seit etwas mehr als zehn Jahren. Athanasios Kallinikidis lernte sie in einem Praktikum kennen und führte sie später in seinem Konzern für die neue Software ein. Voraussetzung war, dass er das Datenmodell des Systems gut genug kannte, um die richtigen Datenpunkte zu verknüpfen.

Die Fußball-Analyse als Vorbild für die Testpriorisierung

Der Auslöser für den Ansatz kam aus dem Amateurfußball. Athanasios trainiert eine Herrenmannschaft in der Kreisliga und nimmt deren Spiele mit Kamera und Hochstativ auf. Eine Software erhebt daraus Statistiken: Heatmaps, Laufwege, woher ein Schuss kam.

Der Leitsatz dahinter: mehr Wissen, weniger Meinung. Wenn ein Spieler behauptet, er sei viel gelaufen, zeigt die Auswertung die tatsächliche Laufleistung. Aus dem realen Spielgeschehen am Sonntag leitet der Trainer ab, was im Training am Dienstag zu tun ist.

Diese Logik lässt sich auf die Softwareentwicklung übertragen. Wenn schon eine Kreisliga-Mannschaft aus ihren Spieldaten für das Training lernt, sollte ein großes IT-Projekt aus seinen Produktionsdaten für die Tests lernen können. Du analysierst, was real passiert, und richtest deine Testaktivität danach aus.

Wir gucken uns an, was in der Realität passiert, leiten dann ab, was wir im Testing machen, und kommen so auf eine stabilere Produktion.

Athanasios Kallinikidis

Warum Workflows der bessere Nenner sind als Geschäftsprozesse

Im konkreten Projekt erwiesen sich nicht die Geschäftsprozesse, sondern die Workflows als tauglicher Nenner. Geschäftsprozesse werden in der Produktion zwar genutzt, im Testing aber häufig unterschätzt und schwer greifbar.

Die abgelöste Software ist im Kern eine große Workflow-Maschine, vergleichbar mit Status-Workflows in einem Ticketsystem. Das Projekt zählt rund 160 verschiedene Workflows: einen Kunden anlegen, einen Vertrag anlegen, ändern, beenden oder vorzeitig ablösen. Jeder dieser 160 Workflows wird modelliert und kann unterschiedlich durchlaufen werden.

Damit ist der Nenner definiert: 160 Workflows. Der Zähler ergibt sich aus den Workflows, die im Test tatsächlich durchlaufen werden. Aus einer Meinung über Abdeckung wird eine zählbare Größe.

Die Top 10 der Durchläufe schlagen die vollständige Abdeckung

Risikobasiertes Testen heißt, die wenigen wichtigen Durchläufe abzudecken statt aller möglichen. Process Mining zeigt, welche Durchläufe wie oft vorkommen, und macht diese Priorisierung begründbar.

Ein Beispiel aus dem Projekt verdeutlicht das Verhältnis. Der aufwendigste Workflow hat über 600 verschiedene Durchläufe. Der häufigste Durchlauf allein deckt rund 20 Prozent ab. Mit den Top 10 Durchläufen erreichst du in Summe etwa 80 Prozent aller Fälle.

Daraus folgt eine klare Entscheidung: Wer Testfälle für die Top 10 Durchläufe hat, kann auf die übrigen 590 verzichten. Nicht aus Bequemlichkeit, sondern weil die Daten zeigen, dass dort der relevante Anteil des realen Geschehens liegt. Und du kannst belegen, warum du genau diese zehn gewählt hast.

Produktionsdaten decken blinde Flecken im Test auf

Der Abgleich von Produktion und Test fördert Workflows zutage, die niemand auf dem Schirm hatte. Manche davon sind harmlos, andere sind echte Lücken.

Die Top 3 der real durchlaufenen Workflows standen im Projekt nicht auf der erwarteten Liste. Der häufigste Workflow ist eine Blacklist-Prüfung über eine Schnittstelle, die entscheidet, ob ein Kunde einen Vertrag erhält. Genau dieser Workflow bereitet im Testen regelmäßig Probleme, weil die Schnittstelle oft nicht funktioniert. Auf Produktion wird er am häufigsten ausgelöst.

Der Abgleich liefert drei Arten von Befunden:

• Grün: Ein Workflow läuft in Produktion häufig und ist im Test angemessen abgedeckt. Bei sehr einfachen Workflows mit nur zwei Durchläufen reichen zwei gute Testfälle, keine dreitausend.
• Gelb: Ein häufiger Produktions-Workflow ist im Test kaum vertreten. Hier lohnt der genaue Blick, ob das richtig sein kann.
• Rot: Ein Workflow gehört zu den Top 10 in Produktion, wird im Test aber kein einziges Mal angetriggert. Das kann nicht stimmen und muss untersucht werden.

Bei einem roten Befund schickst du gezielt jemanden los. Entweder läuft der Workflow in Produktion überflüssig mit und niemand braucht ihn mehr. Oder er muss mitlaufen und fehlt im Test, was ein ernstes Problem ist.

Ohne Automatisierung verfällt der Nutzen wieder

Der größte Hebel des Ansatzes liegt nicht in der einmaligen Analyse, sondern in der Wiederholung. Wer Daten nur manuell einsammelt und aggregiert, ist abhängig davon, dass es einer Person wichtig genug bleibt.

Im Projekt läuft die Auswertung derzeit manuell und regelmäßig. Das funktioniert, solange jemand sie betreibt. Verlässt diese Person das Projekt, endet vermutlich auch die Auswertung. Der manuelle Aufwand ist die eigentliche Schwachstelle.

Dauerhafter Nutzen entsteht erst, wenn das Einsammeln, Aggregieren und In-Beziehung-Setzen der Daten automatisiert ist. Dann greift ein kontinuierlicher Verbesserungsprozess: Das System zeigt regelmäßig Auffälligkeiten, und du gehst nur noch dorthin, wo ein roter Befund auftaucht.

Aufwand und Ertrag müssen in Balance bleiben

Mehr Daten bedeuten nicht automatisch mehr Wert. Auch dieser Ansatz unterliegt dem abnehmenden Grenznutzen, und das Projekt hat seine sinnvolle Grenze bewusst gezogen.

Analysiert wird das zentrale System, um das herum weitere Systeme geschaltet sind. Man könnte alle umliegenden Systeme einbeziehen und so eine vollständigere Messbarkeit erreichen. Die Frage ist nur, wie viel Aufwand das kostet und wie viel zusätzliche Information dabei herauskommt.

Der bestehende Zuschnitt trifft eine gute Balance zwischen Aufwand und Ertrag. Das Ziel ist nicht maximale Vollständigkeit, sondern mit möglichst wenig manuellem Aufwand möglichst viel verwertbare Information herauszuziehen.