Kategorien
Digitale Transformation

Reduktion der Testdaten durch Repräsentanten-Identifikation

Abstract

Im Rahmen der Weiterentwicklung von analytischen Softwaresystemen, wie z. B. einer Risiko- oder Meldesoftware werden häufig Regressionstests durchgeführt, um die Stabilität der Anwendung zu sichern. Dafür wird meistens das vollständige Portfolio aus der Produktion eingesetzt („Brute-Force“-Ansatz), was zu langen Laufzeiten, hohem Speicherplatzbedarf und hohen Analyseaufwänden und letztendlich hohen Kosten führt.

Daher liegt es auf der Hand, den Testdatenumfang möglichst weit zu verkleinern. In diesem Blog wird aufgezeigt, wie die Testdaten mit einem Machine-Learning-Algorithmus automatisiert signifikant reduziert werden können, ohne große Qualitäts­verluste hinnehmen zu müssen, und wie das Testen auf reduzierten Testdaten in der Praxis funktionieren kann.

Dies ist ein großer Schritt in Richtung weniger Testaufwände und -kosten!

Anmerkung: Der Ansatz, der in diesem Artikel beschrieben wird, ist im Kontext des Regressionstests der Meldesoftware Abacus360 (Vendor: BearingPoint Software Solutions GmbH) designt worden, kann aber auch auf andere analytische Systeme übertragen werden.

Ausgangssituation

Im Rahmen der Weiterentwicklung von Abacus360 werden regelmäßig Regressionstests eingesetzt, um die Auswirkungen von verschiedenen Arten von Änderungen zu überprüfen:

  • Änderungen an der Software (Patches / Hotfixes / …)
  • Änderungen an der Datenanlieferung
  • Änderungen an der Parametrisierung
  • Änderungen an Batchketten / Verarbeitungsreihenfolgen
  • Änderungen Workarounds

Jede dieser Änderungen wird i. d. R. separat getestet, da sich die Effekte ansonsten nicht eindeutig zuordnen lassen. Häufig werden alle Testläufe mit dem vollständigen Portfolio durchgeführt. Gerade bei großen Retail-Portfolien führt dies schnell zu langen Laufzeiten, hohem Speicherplatzbedarf und hohen Analyseaufwänden. Ein Lauf kann da schon mal mehr als 24 Stunden dauern, mehrere hundert Gigabyte belegen und mehrere Tage lang analysiert werden.

Antritte, den Testdatenumfang möglichst weit zu verkleinern, sind in der Praxis jedoch oft gescheitert. Ein wesentlicher Grund dafür ist der manuelle Aufwand, die richtigen Testgeschäfte aus dem Portfolio auszuwählen und das Portfolio mit jedem Stichtagswechsel zu pflegen.

Unser Ansatz

Mit dem Ansatz der Repräsentanten-Identifikation mittels Machine-Learning-Algorithmen wird die Auswahl und Pflege relevanter Testdaten automatisiert. Dabei zerlegt ein Klassifikationsalgorithmus – wie in der folgenden Abbildung dargestellt – das gesamte Produktionsportfolio in Cluster mit jeweils gleichen bzw. ähnlichen Geschäften oder Geschäftspartnern und ermittelt jeweils einen oder mehrere Repräsentanten.

Abbildung 1

Durch die Parametrisierung der Klassifikationsalgorithmen können individuelle Bedürfnisse bei der Zusammenstellung der Repräsentanten berücksichtigt werden, wie z. B.

  • Anzahl der Repräsentanten
  • Heterogenität der Cluster
  • Zentren und Randelemente
  • Auswahl bestimmter, spezieller Datensätze („Risikopatienten“)

Vorgehensmodell

In der Praxis erfolgt der Aufbau und die Anwendung von Testportfolien mit der Repräsentanten-Identifikation in fünf Schritten, eingeteilt in drei Phasen.

Abbildung 2

Phase I: Lernphase

In der Lernphase läuft der Klassifikationsalgorithmus über das Gesamtportfolio, bildet Cluster und ermittelt die Repräsentanten (2). Dafür muss das Gesamtportfolio bereitgestellt und eingelesen werden (1). Um einen ausreichenden Lerneffekt zu erzielen, muss dieser Prozess mehrfach, am besten mit mehreren verschiedenen Stichtagen, wiederholt werden. Zudem können verschiedene Parametereinstellungen probiert werden. Das Ergebnis der Lernphase ist ein parametrisierter Algorithmus und eine Liste mit Repräsentaten in Form von Geschäfts- oder Partner-IDs.

Phase II: Anwendungsphase

In der Anwendungsphase werden die Repräsentanten inkl. der abhängigen Entitäten aus dem System extrahiert, z. B. die repräsentativen Geschäfte mit den zugehörigen Partnern, CashFlows, Ratings usw. (3). Dazu kann entweder eine bestehende Exportfunktionalität genutzt werden (präferiert) oder eine selbst entwickelte. Die extrahierten Datensätze stellen die reduzierten Testdaten dar. Diese können nun für beliebige Testläufe genutzt werden (4).

Phase III: Validierungsphase

In der Validierungsphase wird durch Benchmarking der erkannten Fehlerfälle mit denen aus dem Gesamtportfolio die Auswahl der Repräsentanten sukzessive um die typischen Fehlerfälle („Risikopatienten“) verfeinert bis ein bestimmter Abdeckungsgrad an Fehlerfällen mit dem Gesamtportfolio besteht (5). Wenn ein bestimmter Ziel-Prozentsatz (z. B. 99 %) der Fehler im reduzierten Portfolio sichtbar sind, dann ist der Algorithmus zur Erzeugung der repräsentativen Testdaten abschließend kalibriert. Das Benchmarking sollte jedoch auch anschließend noch in regelmäßigen Abständen durchgeführt werden, um ggf. neu auftretende Fehlerfälle zu identifizieren.

Umsetzung

Im Kontext von Abacus360 kann die Umsetzung z. B. folgendermaßen aussehen:

  1. Die Selektion des Gesamtportfolios als Input für den Klassifikationsalgorithmus erfolgt entweder auf der Basis der A360-Eingabedateien (XML-Format) oder direkt aus der A360-Datenbank.
  2. Der Klassifikationsalgorithmus wird in einem externen Rechenkern, z. B. in R oder Python umgesetzt.
  3. Für den Export der Repräsentanten und der abhängigen Entitäten wird der in Abacus360 verfügbare Testdatenexport genutzt.
  4. Die mit dem Export erzeugten Dateien können direkt für neue Testläufe in Abacus360 eingelesen werden.
  5. Beim Benchmarking werden die erzeugten Fehler gegeneinander gehalten, idealerweise automatisiert, z. B. per Makro, ggf. aber auch manuell.
Abbildung 3

Herausforderungen in der Praxis

Die wesentliche Herausforderung in der Praxis ist nicht das Reduzieren der Testdaten sondern die Akzeptanz des reduzierten Testdatensatzes durch die Fachbereiche – aus folgenden Gründen:

  • Beim User Acceptance Test (UAT) und der finalen Abnahme wird eher auf das volle Produktionsportfolio vertraut, da die Befürchtung besteht, dass Spezialfälle in reduzierten Testdaten nicht abgedeckt sind.
  • Fehlerhafte Datensätze aus der Produktion könnten nicht 1:1 in der Testumgebung verfügbar sein, so dass die Fehleranalyse nicht ausreichend gewährleistet ist.
  • Mit Kennzahlen, die sich auf das Gesamtportfolio beziehen, können in einem reduzierten Testdatensatz keine Vorhersagen für das Gesamtportfolio vorgenommen werden.

Folglich ist es für die Akzeptanz eines reduzierten Testdatensatzes wichtig, a) nachzuweisen, dass der reduzierte Satz das Gesamtportfolio zumindest beinahe vollständig repräsentiert und b) immer noch die Möglichkeit zu geben, bei entsprechenden Anwendungsfällen das Gesamtportfolio zu verarbeiten.

Beide Erwartungen können durch einen hybriden Ansatz erfüllt werden, der sowohl Testläufe mit dem reduzierten Portfolio als auch Testläufe mit dem gesamten Portfolio vorsieht. Die Testläufe mit dem Gesamtportfolio decken auf der einen Seite die Anforderungen bzgl. der Abnahme und die Auswertungsmöglichkeiten auf Gesamtportfolioebene ab. Auf der anderen Seiten sollten sie aber auch für ein regelmäßiges Backtesting durchgeführt werden, um dauerhaft die Repräsentatitvität des Testportfolios zu sichern. Alle anderen Läufe können auf dem reduzierten Testdatensatz laufen. In der folgenden Abbildung ist der hybride Ansatz graphisch dargestellt.

Abbildung 4

Fazit

Auch wenn nicht alle Tests auf reduzierten Testdaten durchgeführt werden können, würde selbst die Ausführung der Hälfte aller Testläufe bereits eine signifikante Einsparung an Laufzeiten und Speicherbedarf bringen. Diese kann entweder genutzt werden, um das Testprogramm auszuweiten oder um Hardwarekapazitäten in den Testsystemen zurückzubauen. Letzteres ist besonders erfolgsversprechend, wenn die Hardware in einer Cloud läuft und Kosten nur bei Nutzung anfallen (Hardware on demand). Wenn das nicht der Fall ist, dann sind die Rückbaumöglichkeiten begrenzt, da ansonsten die Performance der Gesamtportfolioverarbeitungen beeinträchtigt werden könnte.

Literatur

Liermann, V., Li, S., & Schaudinnus, N. (2019). Deep learning – an introduction. In V. Liermann, & C. Stegmann, The impact of digital transformation and fintech on the finance professional. New York: Palgrave Macmillan.

Liermann, V., Li, S., & Schaudinnus, N. (2019). Mathematical background of machine learning. In V. Liermann, & C. Stegmann, The impact of digital transformation and fintech on the finance professional. New York: Palgrave Macmillan.

Director, Teamleiter Regulatory Reporting

Christoph Wünnemann ist seit mehr als 14 Jahren Berater bei der ifb group und hat dabei zahlreiche Kunden im Umfeld des regulatorischen Meldewesens unterstützt, insbesondere mit der verbreiteten Meldesoftware ABACUS360. Als Teamleiter und Themenverantwortlicher treibt er innovative Ideen in diesem Kontext voran.