Testdatenmanagement

Testdatenmanagement bezeichnet die strukturierte Bereitstellung, Übertragung und Anonymisierung von Testdaten über mehrere Systeme hinweg. Ziel ist es, Tester in die Lage zu versetzen, Daten selbst zu bestellen, ohne zentrale Gruppen einzuschalten. Ein einheitliches Applikationsmodell beschreibt dabei die fachlichen Bausteine wie Kunde oder Vertrag systemübergreifend und verhindert redundante Lösungen.

Das Wichtigste in Kürze

• Ohne konsistente Testdaten sind Testergebnisse nicht aussagekräftig, egal wie ausgereift die Testmethoden und Automatisierungstools dahinter sind.
• Fünf oder sechs selbst entwickelte Einzelwerkzeuge für Testdaten führen zu Redundanz und hohem Pflegeaufwand, weil jede kleine Änderung im Zielsystem Anpassungen in allen Tools erzwingt.
• Ein zentrales Testdatenmanagementsystem macht manuelle Prozesse wie den kompletten Umgebungsaufbau überflüssig, weil Tester Daten per Web-Oberfläche selbst bestellen und per Klick schedulen können.
• Dateninkonsistenzen in Testsystemen bleiben oft unentdeckt, bis sie zu Programmabbrüchen führen, weil kein Mechanismus aktiv meldet, wenn referenzierte Einträge fehlen.

Warum Testdaten das Fundament jedes Testergebnisses sind

Testdaten entscheiden über die Aussagekraft eines Tests. Wenn die Daten falsch sind, sind auch die Testergebnisse hinfällig, egal wie gut die Methoden und Werkzeuge dahinter funktionieren. In der Diskussion um Testmanagement landet der Fokus oft bei Automatisierung und Tooling, während die Datenbasis stillschweigend vorausgesetzt wird.

Patrick Olcha von Union Investment beschreibt den Ausgangspunkt am Beispiel eines stark parametrisierbaren Systems. Zwischen Produktion und Testumgebung gab es Abweichungen bei den Parametern. Diese Parameter hatten Auswirkungen auf das Verhalten der Anwendung. Ohne identische Datenbasis lässt sich nicht zuverlässig sagen, dass ein Ergebnis aus dem Test auch in Produktion so eintritt.

Daraus wuchs eine Kette weiterer Anforderungen. Umgebungen mussten mit frischen Daten versehen werden. Produktionsfehler sollten sich nachstellen lassen. Und Daten durften nicht beliebig zwischen Umgebungen wandern, weil Anforderungen aus verschiedenen Bereichen das einschränkten.

Wie aus Insellösungen ein Pflegeproblem wird

Selbstgebaute Werkzeuge lösen einzelne Probleme, erzeugen aber Folgekosten. Bei Union Investment entstanden so fünf bis sechs verschiedene Werkzeuge für Testdaten. Die Pflege war aufwendig, und schon kleine Änderungen im Zielsystem zogen viel Anpassungsbedarf in den einzelnen Tools nach sich.

Dazu kam Redundanz. Zwei oder drei Werkzeuge funktionierten ähnlich, aber nicht gleich. Diese Doppelung war nicht gewollt, sondern durch technische Rahmenbedingungen erzwungen. An diesem Punkt entstand die Erkenntnis, dass die Verwaltung anders laufen muss.

Ein zweites Muster verschärft das Problem in verteilten Landschaften: Daten laufen über Systeme hinweg auseinander. Bei Union Investment hängen am Kernbestandsführungssystem, einem Datenbankmanagementsystem, angrenzende Systeme wie ein Data Warehouse und diverse Hilfsdatenbanken. Eine systemübergreifende Übertragung der Daten war mit den alten Lösungen nicht sauber möglich.

Dateninkonsistenz wird erst sichtbar, wenn sie wehtut

Inkonsistente Daten innerhalb eines Systems bleiben oft unbemerkt, bis ein Programm darüber stolpert. Ein typischer Fall: Ein Programm erwartet zusammengehörige Einträge in zwei Tabellen, findet aber nur den Eintrag in Tabelle A, weil der korrespondierende Eintrag in Tabelle B manuell gelöscht oder verändert wurde. Das Ergebnis ist ein Programmabbruch.

Das Tückische daran ist die fehlende Rückmeldung. Wer die Inkonsistenz verursacht hat, weiß es im Zweifel selbst nicht, und das System meldet sie nicht aktiv. Sichtbar wird der Schaden erst über den Abbruch.

Eine pragmatische Gegenmaßnahme ist eine klare Definition von Konsistenz mit einer Eskalation: Trifft die Definition nicht zu, wird der betroffene Datensatz im Zweifel komplett gelöscht. Ein sauber gelöschter Datensatz ist besser als ein inkonsistenter, der unkontrolliert weiterwirkt.

Was ein modellbasiertes Testdatenmanagement leisten muss

Die zentralen Anforderungen lassen sich auf wenige Punkte verdichten. Sie zeigen, worauf es bei einer übergreifenden Lösung ankommt:

• Mehrere Datenbankmanagementsysteme müssen unterstützt werden, nicht nur das Kernsystem.
• Self-Service für Anwender: Tätigkeiten, die früher nur eine zentrale Gruppe ausführen durfte, sollen die Nutzer selbst erledigen können.
• Abbildung des Applikationsmodells: Der Anwender wählt bausteinweise aus, was er braucht, etwa Kunde, Vertrag oder Umsätze.
• Wiederverwendbarkeit: Einmal beschriebene Bausteine, Datenmodelle oder Anonymisierungsmethoden sollen nicht pro System neu definiert werden müssen.

Die Wiederverwendbarkeit adressiert genau den Schmerz der alten Insellösungen. Eine Methode zur Anonymisierung von Namen wird einmal definiert und dann über Systeme hinweg genutzt, statt sie für jedes Datenbanksystem erneut zu bauen.

Wie eine Modellierungsschicht über Systemgrenzen hinweg funktioniert

Eine Abstraktionsschicht trennt das fachliche Modell von der konkreten Datenbank dahinter. Danny Tamm von UBS Heiner beschreibt das Prinzip so, dass einzelne Module zu einem Modell zusammengebaut werden, ohne dass die dahinterliegende Datenbank eine Rolle spielt. Wo die Daten physisch liegen, wird einmal pro Umgebung definiert.

Über diesem Modell liegt eine weitere Schicht für die Endanwender. Sie sehen weder die Datenbank noch das Modell, sondern bestellen ihre Daten. Dazwischen liegt die beschreibende Schicht, ganz unten die Datenbank.

Die Kopplung über Systemgrenzen entsteht an genau einem Punkt, dem gemeinsamen Ordnungsbegriff. Gibt es etwa eine Kundennummer im Kernsystem und im CRM weitere Daten zu derselben Kundennummer, verbindet dieser Schlüssel die Applikationsmodelle beider Systeme. Wichtig dabei: Jedes Modell bleibt auch einzeln nutzbar. Wer auf einer niedrigeren Teststufe nur in einem System testet, lässt die anderen einfach weg.

Testdaten bestellen statt anfordern

Das Bestellprinzip funktioniert wie ein Online-Shop für Daten. Der Anwender gibt über eine Weboberfläche vor, welche Daten er braucht, etwa einen bestimmten Kunden oder ein Konto, dazu Quelle und Ziel der Bewegung. Ein Klick auf Bestellen stößt im Hintergrund die Prozesse an, die in der Quelle lesen, anonymisieren und ins Ziel schreiben.

Den Inhalt des Shops definiert das Team selbst. Festgelegt wird, was und in welchen Tabellen anonymisiert wird, welche Aufgaben den Endanwendern überhaupt zur Verfügung stehen und wer was tun darf. Manche Bereiche sind einem bestimmten Personenkreis vorbehalten, andere kann jeder Nutzer selbst ausführen oder per Request senden.

Die Bedienung bleibt bewusst einfach, auch wenn im Hintergrund viel passiert. Beim Kopieren zwischen Umgebungen hat die Maske drei Felder: Quellumgebung, Zielumgebung und das zu übertragende Objekt, etwa eine konkrete Nummer.

Mit dem einfachsten Ablauf wird gefühlt jeder Bereich der Software durchlaufen, und dann haben sie die Daten so, wie sie wollen.

— Patrick Olcha, Union Investment

Von einfachem Löschen bis zum kompletten Umgebungs-Refresh

Die Anwendungsfälle staffeln sich nach Komplexität und Berechtigung. Der einfachste Fall ist das Löschen eines einzelnen inkonsistenten Datensatzes. Diese Funktion gab es früher gar nicht: Entweder wurde die gesamte Umgebung neu aufgebaut oder der inkonsistente Stand blieb stehen.

Der nächste Fall ist das Kopieren zwischen Umgebungen, etwa zwischen Teststufen oder aus der Produktion heraus, um einen Produktionsfehler nachzustellen. Den komplexesten Fall bildet der Refresh einer kompletten Umgebung. Dieser Ablauf besteht aus rund acht aufeinanderfolgenden Schritten, von denen jeder auf 20 bis 300 Tabellen zugreift.

Genau dieser Refresh war zuvor ein manueller Prozess in einer zentralen Gruppe. Jetzt lässt er sich per Klick auslösen und über einen Scheduler auf Randzeiten legen. Das hat einen handfesten Grund: Über JDBC werden je Tabelle Datensätze im zweistelligen Millionenbereich übertragen, ein Insert von etwa 60 Millionen Datensätzen braucht seine Zeit.

Ein Proof of Concept lebt von einer vorhandenen Basis

Die Migration gelingt schneller, wenn bereits Erfahrung und ein Modell vorhanden sind. Union Investment hatte aus dem eigenen Fondssystem eine Ausgangsbasis und konnte sie in das Zielsystem migrieren. Dabei traten nur zwei bis drei Fehler auf, danach war das Modell im Zielsystem abgebildet.

Von dieser Basis aus lässt sich das Modell schrittweise verbessern. Der heutige Stand ist ein Monolith aus rund 300 Tabellen, die zusammengehören, aber noch nicht nach Kunden und Bereichen aufgeteilt sind. Parallel zur gesicherten Ausgangsbasis entstehen kleinere Applikationsmodelle als Inseln, die sich bei Bedarf miteinander verbinden lassen.

Ein Endzustand ist dabei nicht das Ziel. Mit der Nutzung der Software entstehen laufend neue Ideen und Möglichkeiten. Diese Offenheit ist gewollt, denn genau dafür ist das Werkzeug da.

Akzeptanz entsteht durch Self-Service und neue Funktionen

Die positive Resonanz speist sich vor allem aus zwei Quellen: Anwender können Dinge selbst erledigen, und sie bekommen Funktionen, die es vorher nicht gab. Das eigenständige Löschen einzelner Depots ist ein Beispiel für eine Funktion, die früher schlicht fehlte. Statt eine Anfrage zu stellen oder andere zu kontaktieren, klicken sich die Nutzer selbst durch.

Der Rollout läuft über friendly user. Zunächst nutzen 20 bis 30 Anwender das System intensiv, der nächste Schritt ist die Verbreitung in die Breite, damit deutlich mehr Leute in der Organisation darauf zugreifen können. Parallel dazu werden die noch manuellen Prozesse rund um das Bestandsführungssystem vollständig abgelöst.

Daneben steht die Anbindung weiterer Systeme. Über die bereits gekoppelten hinaus gibt es einen vierten Kandidaten. Wie schnell das geht, hängt an Ressourcen und Budget, etwa daran, ob die jeweiligen Datenbankmanagementsysteme bereits lizenziert sind.