Systemwechsel als Chance für zeitgemäße Testdatenautomation nutzen

Beispiel für eine typische Ausgangslage vor dem Einsatz einer automatisierten TDM Lösung wie XDM von UBS-Hainer.

Die folgende Beschreibung bildet das reale Beispiel eines großen Versicherers und Kunden von UBS Hainer ab. Dieser konnte durch den Einsatz der Testdatenmanagement-Software „XDM“ alle seine Herausforderungen meistern (und steht übrigens als Referenzkunde jederzeit für diesbezügliche Nachfragen und Auskünfte zur Verfügung).


Und das war die Ausgangslage bzw. Aufgabenstellung:


Das IT-technische Rückgrat des Versicherers war ein in den 1990er Jahren entwickeltes Versicherungs-Agentursystem. Dabei handelte es sich im Wesentlichen um ein monolithisches System mit einer zentralen Hausdatenbank, in der sämtliche Daten gelagert waren.

 

Durch diese Konstellation war es relativ einfach, Testdaten zu generieren. Dazu zapfte man einfach den zentralen Datentopf mit Produktivdaten an. Die gewünschten Datensätze wurden herunterkopiert und auf die verschiedenen Testsysteme verteilt. Während des Kopiervorgangs wurden gleichzeitig die personenbezogenen Informationen in den Datensätzen pseudonymisiert. Der komplette Vorgang des Kopierens, Verteilens und der Pseudonymisierung wurde mittels eines auf dem Host selbst entwickelten Software-Tools bewerkstelligt.

All das hat recht gut funktioniert, bis man dann im Jahr 2015 gewisse Grenzen erreichte. Die Constraints bei den Anwendungen nahmen zu. Es gab Handlungsbedarf – nicht zuletzt, um den IT-technischen Anschluss nicht zu verlieren.


Umstrukturierung der Produktivdaten

 

Daher begann man im Jahr 2015, eine Nachfolgelösung aufzubauen und dazu das bestehende Versicherungs-Agentursystem umzubauen. Das neu entstandene System basiert – zumindest in Teilen – auf einem Self-Contained-Systems-Ansatz. Dazu wurde das bisher monolithische System in Teilsysteme verschiedener fachlicher Anwendungskomponenten zerschlagen. Diese Teilsysteme sind in sich geschlossen und kommunizieren untereinander über REST bzw. Kafka Schnittstellen.

 

Rein praktisch führte dies dazu, dass die Datensätze jetzt nicht mehr wie vorher komplett in einer Hausdatenbank liegen, sondern über mehrere Datenbanken hinweg verteilt sind. So liegen z.B. die Stammdaten eines Kunden in einer der Datenbanken, die Vertragsdaten „Kfz“ in einer anderen und weitere Vertragsdaten in weiteren Datenbanken.

 

Hinzu kommt, dass es sich bei diesen Datenbanken nicht um eine homogene Datenbanklandschaft handelt. Vielmehr werden mehrere Datenbanktypen parallel eingesetzt. Einige der für Testzwecke benötigten Daten liegen z.B. auf einer IBM LUW, andere in einer PostgreSQL. Aber auch das IBM DB2/zOS System wird – voraussichtlich bis zum Jahr 2030 – verwendet. Auch dort werden also weiterhin produktive Daten liegen, die für Tests gebraucht werden.


Die bisherige TDM-Lösung funktionierte nicht mehr

 

Was bedeuten diese Änderungen nun für die Beschaffung von Testdaten? Im Zuge der Umstrukturierung wurde die Beschaffung von Testdaten zu einer massiven Herausforderung. Die bisher bewährte Lösung funktioniert nicht mehr.

 

Wird nun ein kohärenter Datensatz zu Testzwecken benötigt, müssen die jeweils benötigten Teildaten auf den verschiedenen Systemen gefunden, kopiert und dann zu einem kompletten Satz kombiniert werden. Gleichzeitig muss dieser Testdatenfall konsistent pseudonymisiert werden.

 

Der so entstehende DSGVO-konforme Testdatenfall muss nun in das jeweilige Testsystem kopiert und dort wieder auf die verschiedenen Datenbanksysteme verteilt werden. Dabei müssen die authentischen Relationen bestehen bleiben. All das muss automatisiert und je nach Bedarf mit hunderttausenden Datensätzen erfolgen. Dazu braucht es ein stabiles und erprobtes System, das gleichzeitig von mehreren hundert Entwicklern genutzt werden kann.

 

Letztlich suchte man zur Ablösung des Bestandssystems eine neue Lösung, die mit der verteilten Welt zurechtkommt aber auch problemlos auf die zOS-Welt zugreifen kann. Und es musste möglich sein, dieses System im laufenden Betrieb zu implementieren. Der beschriebene Versicherer kam zu dem Schluss, dass XDM von UBS Hainer diese Herausforderungen meistern kann. Es wurde ein PoC aufgesetzt, und in der Folge wurde die Testdatenautomation erfolgreich implementiert.


AKTUELLE BEITRÄGE

XDM – Agiles Tool für agile Teams: Was bedeutet das?

Die zunehmende Notwendigkeit für Continuous Deployment rückt auch zwangsläufig das kontinuierliche Testen in den Fokus. Wir fragen Christoph Stock, Manager für Produktentwicklung bei UBS-Hainer: Lässt sich das denn bei den benötigten Datenmengen und -qualitäten überhaupt noch ohne Testdatenautomation umsetzen?

MEHR »

Einführung der Testdatenautomation: Wie man alle Beteiligten ins Boot holt

Ein agiles Tool zur automatisierten Beschaffung von Testdaten tangiert verschiedene Fachbereiche im Unternehmen. Daher müssen im Vorfeld der Implementierung alle Beteiligten vom Nutzen der Maßnahme überzeugt sein. Dies stellt sich zuweilen als komplexe Aufgabe dar. UBS Hainer unterstützt bei der Koordinierung und Beschleunigung dieses Prozesses.

MEHR »

Qualitativ hochwertige Testdaten werden immer wichtiger

Noch vor 20 Jahren arbeitete IT bei der Interaktion mit dem Endverbraucher weitgehend im Hintergrund. Heute hat sich das grundlegend geändert. IT ist viel sichtbarer geworden, und der Umgang mit Benutzeroberflächen gehört inzwischen zum Standardrepertoire jedes Verbrauchers. Was bedeutet das für die Software-Entwicklung?

MEHR »

Grünes Licht für automatisiertes
Testdatenmanagement

Nutzen Sie unsere kostenlose Erstberatung, um schnell und unkompliziert Ihre optimalen und individuellen Optionen zu ermitteln!

Green traffic light