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.
Häufig gestellte Fragen
Wie lässt sich begründen, ob die Testabdeckung eines Projekts ausreicht?
Testabdeckung ist im Kern eine Prozentrechnung: Zähler durch Nenner. Ohne definierten Nenner bleibt jedes Urteil über “zu wenig” oder “genug” eine Meinung. In einem Ablöseprojekt für eine Altsoftware lautete deshalb die Gegenfrage auf den Vorwurf schlechter Regressionstestabdeckung: Was genau ist der Nenner? Erst wenn die Bezugsgröße offenliegt, wird die Abdeckung zählbar.
Was zeigt Process Mining, was ein Prozessmodell nicht zeigt?
Es zeigt den gelebten Ist-Ablauf statt des gezeichneten Soll-Diagramms. Jeder Klick und jede Aktion in einem digitalen System hinterlässt eine Spur. Ein Process-Mining-Werkzeug sammelt diese Spuren ein und setzt sie in Beziehung. Voraussetzung ist, dass jemand das Datenmodell des Systems gut genug kennt, um die richtigen Datenpunkte zu verknüpfen.
Eignen sich Geschäftsprozesse oder Workflows besser als Bezugsgröße für Testabdeckung?
Im beschriebenen Projekt erwiesen sich Workflows als tauglicher Nenner. Geschäftsprozesse werden in der Produktion zwar genutzt, im Testing aber häufig unterschätzt und bleiben schwer greifbar. Die abgelöste Software war im Kern eine Workflow-Maschine mit rund 160 modellierten Workflows: Kunde anlegen, Vertrag anlegen, ändern, beenden. Der Zähler ergibt sich aus den im Test tatsächlich durchlaufenen Workflows.
Müssen alle möglichen Durchläufe eines Workflows durch Testfälle abgedeckt sein?
Nein. Der aufwendigste Workflow im Projekt hatte über 600 verschiedene Durchläufe. Der häufigste allein deckte rund 20 Prozent der Produktionsfälle ab, die Top 10 zusammen etwa 80 Prozent. Wer Testfälle für diese zehn besitzt, kann auf die übrigen 590 verzichten und die Auswahl mit Zahlen aus der Produktion begründen.
Wie erkennt man Workflows, die im Test fehlen, aber in der Produktion wichtig sind?
Über den Abgleich der Produktionshäufigkeit mit den im Test ausgelösten Workflows. Grün heißt: häufig in Produktion und angemessen abgedeckt. Gelb heißt: häufig, im Test kaum vertreten. Rot heißt: unter den Top 10 in Produktion, im Test kein einziges Mal ausgelöst. Bei Rot ist entweder der Workflow überflüssig oder er fehlt im Test.
Reicht eine einmalige Auswertung der Produktionsdaten aus?
Nein, der Hebel liegt in der Wiederholung. Wird manuell eingesammelt und aggregiert, hängt alles daran, dass es einer Person wichtig bleibt; verlässt sie das Projekt, endet meist auch die Auswertung. Erst automatisiertes Sammeln und In-Beziehung-Setzen trägt einen kontinuierlichen Verbesserungsprozess, bei dem du nur noch roten Befunden nachgehst.
Sollte man möglichst viele angebundene Systeme in die Analyse einbeziehen?
Nicht zwangsläufig, denn auch hier greift der abnehmende Grenznutzen. Im Projekt wird das zentrale System analysiert, um das herum weitere Systeme geschaltet sind. Alle umliegenden Systeme einzubeziehen würde die Messbarkeit vervollständigen, kostet aber Aufwand. Das Ziel ist nicht maximale Vollständigkeit, sondern viel verwertbare Information bei wenig manuellem Aufwand.
