Configuration

In der Regel besteht die Bereitstellung von Testdaten aus mehr als der einfachen Kopie von Daten von einigen Tabellen in andere Tabellen. Nach der Bestellung müssen die Eingabedaten gegen die Quell- und Zielverbindung verifiziert werden. Bestimmte sensitive Daten dürfen auch nicht pseudonomisiert auf Testumgebungen kopiert werden. Zusätzlich soll der Umfang der Bestellung geprüft werden um andere Bereitstellungen oder die Verfügbarkeit nützlicher Testdaten nicht zu gefährden.

Oftmals müssen auch Eingabedaten zunächst in eine technisch abarbeitbare Form gebracht werden. Je nach Selektion einzelner Sparten oder Datenbereiche müssen Konfigurationen der Testdatenmodellierung dynamisch ausgeschaltet werden. Zum Beispiel ist es möglich bei der Kopie eines Versicherungsvertrags etwa nur die Vertrags- und Personendaten zu kopieren, die Schadensmeldungen auszulassen.

Vor Durchführung der Kopie der Daten muss in der Regel auf dem Zielsystem der Bestand der identischen Daten gelöscht und zurückgesetzt werden. Dazu kann man einen entsprechenden Löschtask vor Durchführung des Kopiertasks setzen.

Nach der Durchführung der eigentlichen Datenoperation kann es notwendig sein, bestimmte Services zu rufen um Caches zu leeren oder Indexe neu aufzubauen.

Auch eine Benachrichtigung an den Besteller bei Erfolg oder eine zusätzliche Benachrichtigung der Administratoren bei einem unerwarteten Fehler kann nach Durchführung des Workflows hilfreich sein.

Bestimmte Testdatenbereitstellungsläufe müssen zu einem bestimmten Zeitpunkt oder regelmäßig durchgeführt werden. Zudem kann es bei der Verwaltung der Testebenen helfen, die Datenbanken und Strukturen regelmäßig auf korrekte Konfiguration und Strukturunterschiede untersuchen zu lassen, um mögliche Probleme bereits vor einer benötigten Testdatenbereitstellung zu erkennen. Dazu kann jede Konfiguration im XDM im internen Scheduler geplant werden.

Das notwendige Wissen über alle technischen und fachlichen Aspekte, die für die Aufstellung eines Testdatenprozesses notwendig sind, verteilt sich in einem Konzern über viele Personen, Abteilungen und Teams.

Informationen zu Servern, Datenbankverbindungen, Netzwerk-Setups und Laufwerken liegen bei Infrastruktur-Teams.

Die Betreuung von Regelwerken von der Anonymisierung wird vom Datenschutz festgelegt und überwacht, die Umsetzung der Methoden wiederum liegt bei Entwicklern. Die Anbindung der Methoden an konkrete Tabellen und Spalten wiederum kann ggf. nur von den konkreten Anwendungsteams durchgeführt werden.

Die Zusammenhänge von Tabellen zur Abbildung der Applikationsdaten sind teilweise nur den einzelnen Teams bekannt und sollten auch von diesen betreut werden, um bei Änderungen am Modell das Wissen direkt in die Konfiguration des Testdatenbereitstellungsprozesses überführen zu können.

Skripte zum Aufruf externer Tools oder z.B. zur Benachrichtigung können einmalig zentral von einem TDM-Team entwickelt werden und stehen dann allen Entwicklern von Tasks und Workflows zur Verfügung.

Die XDM Plattform wird zum Wissens- und Konfigurationsspeicher für alle Informationen zur Testdatenbereitstellung.

Um maßgeschneiderte Testdaten bereit stellen zu können sind fundamentale Kenntnisse der Anwendung notwendig. Nur wenn man weiß wie die zu testende Anwendung die Daten ablegt, welche Relationen es zwischen Entitäten gibt und was geschäftskritische Daten sind, kann ich geeignete Testdaten bereitstellen.

Mit XDM lässt sich die zu testende Anwendung zentral modellieren. Alle Entitäten (Tabellen) und deren Beziehungen untereinander werden erfasst. Außerdem können anwendungsspezifische Ordnungsbegriffe definiert werden. Dies sind in der Regel die Begriffe, die die Anwender intern gebrauchen und die auch im Testdatenmanagementsystem genutzt werden können. Dies erleichtert den Nutzern der Testdaten sich leicht und verständlich Daten für ihren Anwendungsfall zusammenzustellen.

Unabhängig wo und auf wie viele Datenbanksysteme die Daten abgelegt werden, können diese in XDM modelliert und über Datenbankgrenzen hinweg verknüpft werden. Beim Bereitstellen der Testdaten sorgt XDM dafür, dass die Daten in allen involvierten System nach den Vorgaben des Anwenders kopiert werden und somit neue Testfalldaten entstehen.

Kernstück von XDM ist die Möglichkeit, die Fachdomäne einer Anwendung explizit zu modellieren. Anstatt mit rein technischen Datenstrukturen wie relationalen Tabellen oder REST-API-Antworten zu arbeiten, fokussiert XDM auf die bekannten Fachobjekte – die sogenannten Domain Entities. Diese werden im Rahmen eines Domain Models erfasst, einem Konzept, das sich an bewährten Prinzipien des Domain Driven Design (DDD) orientiert.

Ein Domain Model dient als fachliches Abbild der Datenstrukturen und repräsentiert zentrale Objekttypen der jeweiligen Anwendungsdomäne, beispielsweise Verträge oder Kunden. Jede Entity steht dabei für ein eigenständiges Fachobjekt und verfügt über klar definierte Attribute, wie „Vertragsnummer“ oder „Kundenname“. Die Attribute spiegeln die relevanten Eigenschaften der Fachobjekte wider und bilden so die Grundlage für eine nutzerzentrierte Datenverarbeitung.

Die Verfremdung personenbezogener Daten, die fachliche Veränderung der Daten oder die Anpassung der Daten an neuere Programmversionen sind Basisanforderungen bei der Bereitstellung von Testdaten. Für all diese Einsatzzwecke kann die Modifikation genutzt werden.

In der Regel ist die Definition wie bestimmte Attribute (Vornamen, Nachnamen, Adressen, etc.) zu verfremden sind gegeben oder wird zentral erarbeitet. Das Wissen in welchen konkreten Tabellen und Spalten diese Informationen vorliegen, und in welcher spezifischen Form, liegt an einer anderen Stelle. Daher wird diese Konfiguration im XDM getrennt verwaltet, sodass die Definition der Modifikation modular an konkrete Tabellen gebunden werden kann.

Die dynamische, regelbasierte Konfiguration der Modifikation erlaubt es, diese beliebig in Tasks des XDM anzuwenden. Sowohl bei der Massendatenbereitstellung, als auch bei der Kopie von Teilmengen kann die identische Konfiguration verwendet werden.

Die Modifikation selbst erfolgt immer innerhalb des XDM Systems, sodass jede Modifikation unabhängig vom verwendeten Datenbanksystem verwendet werden kann. Dies ermöglicht eine konsistente Modifikation auch über verschiedene Systeme hinweg. Zusätzlich spart die externe Modifikation Rechenleistung auf den Datenbanksystemen. In allen Standardkonfigurationen müssen keinerlei unmaskierte Daten auf dem XDM System persistiert werden.

Neben der Modifikationsengine selbst bietet XDM auch eine große Anzahl an Hilfsfunktionalitäten, die zur Umsetzung konsistenter, deterministischer Maskierung genutzt werden können. Diese enthalten zum Beispiel die Möglichkeit stabile Hashes zu berechnen und auf dieser Grundlage Lookup-Tabellen zu verwenden.

Vorgefertigte Methoden für übliche Attribute wie Namen, Adressen, Bankdaten usw. bringt XDM mit. Ebenso passende Lookup-Tabellen in mehreren Sprachen mit länderspezifischen Datensätzen.

Die Methoden lassen sich vollständig selbst in Skripten verfassen, die Basismethoden können dabei als Ausgangsbasis verwendet werden. Darüber hinaus werden eine Vielzahl an Beispielen für gängige Projekte in der Supportdatenbank angeboten.

Auch die Filterung oder Vervielfältigung von Daten mithilfe der Modifikation ist möglich. Dies eröffnet viele weitere Einsatzmöglichkeiten wie die Generierung von synthetischen Testdaten. Auf Basis eines einzelnen Datentemplates lassen sich so beliebig angepasste und individualisierte Testdatensätze produzieren. Unsere Kunden nutzen diese Methoden, um Daten zu erzeugen und in Testsysteme zu integrieren, die so noch nicht in der Produktion vorliegen. Für manche Tests sind solche, neuen, nicht vorhandene Datenkonstellationen zwingend erforderlich.