Im ersten Teil dieser Serie standen die aktuellen Herausforderungen im Testdatenmanagement im Mittelpunkt: fachlich anspruchsvolle Anforderungen, verteilte Datenbestände, Datenschutz, organisatorische Abstimmungen und die Frage, wie XDM diese Aufgaben bereits heute unterstützt.
XDM deckt dabei den Weg von der Modellierung relevanter Datenquellen bis zur Auswahl und Bereitstellung geeigneter Testdaten ab.
Die naheliegende Frage lautet nun: Wie könnte der nächste Schritt aussehen?
Wenn Testdaten heute bereits über definierte Prozesse, Suchmechanismen und Bestelloberflächen bereitgestellt werden können, liegt eine Weiterentwicklung nahe: Was wäre, wenn Entwickler und Tester ihren Bedarf künftig direkt in natürlicher Sprache formulieren könnten?
Genau an dieser Stelle entsteht ein interessantes Zusammenspiel aus LLM, MCP und XDM.
Testdaten per Prompt anfordern
Ein denkbares Zukunftsszenario ist schnell beschrieben: Ein Entwickler arbeitet in seiner IDE oder nutzt einen internen Assistenten und formuliert dort seinen Bedarf unmittelbar in Fachsprache:
Ich brauche 10 KFZ-Versicherungsverträge, bei denen im letzten Jahr mehr als zwei Schäden gemeldet wurden und der Vertragsnehmer mehrere aktive Verträge besitzt.
Bitte stelle mir diese Fälle in meiner Testumgebung bereit.
In einem solchen Ablauf würde ein LLM die fachliche Absicht der Anfrage interpretieren und in eine strukturierte Anforderung überführen.
Über einen MCP-Server könnten passende XDM-Funktionen als Werkzeuge angebunden werden.
XDM würde dann die operative Ausführung übernehmen, etwa indem es:
- die Anfrage in Such- und Selektionskriterien übersetzt
- geeignete Datenkonstellationen identifiziert
- definierte Bereitstellungsprozesse anstößt
- sensible Inhalte regelbasiert modifiziert
- die Daten kontrolliert in eine Zielumgebung überführt
Der entscheidende Unterschied läge damit nicht in einem neuen Kopiermechanismus, sondern in einer neuen Form der Interaktion: Der Anwender beschreibt seinen fachlichen Bedarf, und das System leitet daraus die technische Umsetzung ab.
XDM als operative Ebene hinter dem Prompt
Wichtig ist dabei die Einordnung der Rollen: Ein LLM würde das Testdatenmanagement nicht ersetzen, sondern den Zugang dazu vereinfachen.
Die belastbare operative Ebene bliebe XDM.
Dort liegen die modellierten Anwendungen, die Beziehungen zwischen Daten, die Logik für Suche und Bereitstellung sowie die Regeln für Modifikation und Prozessausführung.
XDM ist bereits heute auf Self-Service und anforderungsgetriebene Bereitstellung ausgelegt, etwa über den Data Shop.
In einem KI-gestützten Szenario würde also nicht die Plattform ausgetauscht.
Erweitert würde vor allem die Benutzerinteraktion: Statt eine Bestellmaske auszufüllen, könnte ein Anwender seinen Bedarf direkt formulieren.
Vom Formular zum Dialog
Gerade darin liegt ein wesentlicher Mehrwert.
Self-Service funktioniert heute meist über vordefinierte Eingabemasken.
Das ist sinnvoll und in vielen Szenarien weiterhin der richtige Weg.
Mit dem Data Shop stellt XDM dafür bereits einen etablierten Mechanismus bereit, über den Endanwender definierte Prozesse anfordern können.
Ein LLM-gestützter Ansatz könnte diese Logik jedoch um eine zusätzliche Ebene ergänzen: den Dialog.
Statt sich an Feldern, Parametern und technischen Begriffen zu orientieren, könnte der Nutzer in seiner eigenen Sprache beschreiben, was fachlich benötigt wird.
Das LLM würde diese Beschreibung interpretieren, bei Bedarf Rückfragen stellen, fehlende Angaben präzisieren und die Anfrage anschließend in eine strukturierte Ausführung überführen.
Gerade für Entwickler und Tester wäre das ein praxisnaher Schritt.
Der Bestellprozess für Testdaten würde sich stärker an ihrer tatsächlichen Arbeitsweise orientieren und sich zugleich besser in bestehende Entwicklungs- und Testabläufe einfügen.
MCP als Vermittler zwischen KI und XDM
Damit ein LLM nicht nur Texte erzeugt, sondern gezielt Aktionen in operativen Systemen auslösen kann, braucht es eine klar definierte und kontrollierbare Anbindung.
Hier kann MCP eine wichtige Rolle übernehmen: als Vermittlungsschicht zwischen Sprachmodell und XDM-Funktionen.
In einem solchen Aufbau würde das LLM nicht direkt auf Datenbanken oder Prozesse zugreifen, sondern über definierte Schnittstellen mit XDM interagieren.
XDM bringt dafür bereits technische Integrationsmöglichkeiten über APIs, Workflows und weitere Aufrufe mit.
MCP wäre in diesem Bild also nicht das eigentliche Testdatenmanagement, sondern die Verbindungsschicht, über die ein LLM passende XDM-Funktionen gezielt ansprechen kann.
Gerade aus Sicht von Governance, Nachvollziehbarkeit und kontrollierter Ausführung ist diese Trennung relevant.
Denn je stärker natürliche Sprache zum Einstiegspunkt für operative Prozesse wird, desto wichtiger werden klare technische Zuständigkeiten im Hintergrund.
Fachliche Suche deutlich zugänglicher machen
Ein besonders naheliegender Anwendungsfall ist die fachliche Suche nach geeigneten Testfällen.
Mit dem Test Data Finder bietet XDM bereits eine Grundlage, um passende Datenkonstellationen in heterogenen Umgebungen zu identifizieren.
Ein LLM könnte darauf aufsetzen und Suchanfragen nicht mehr nur über vorbereitete Felder, sondern über natürlich formulierte Beschreibungen entgegennehmen.
Das ist vor allem dort interessant, wo der Bedarf fachlich zwar klar ist, sich aber nicht ohne Weiteres in konkrete Suchparameter übersetzen lässt.
Statt Suchmasken manuell zu bedienen, könnte der Anwender zunächst beschreiben, welchen Fall er benötigt.
Das System würde daraus eine präzisere Suchanfrage ableiten, bei Bedarf Rückfragen stellen und gefundene Konstellationen anschließend direkt an die Bereitstellung übergeben.
Das kann den Zugang zu Testdaten spürbar vereinfachen, insbesondere in gewachsenen Systemlandschaften, in denen Fachlichkeit, Datenstrukturen und technische Selektionslogik nicht immer deckungsgleich sind.
Unterstützung direkt in der IDE
Noch interessanter wird dieses Zukunftsbild, wenn man nicht bei der Datenbereitstellung stehen bleibt.
Denkbar ist beispielsweise, dass ein Entwickler direkt in seiner IDE formuliert:
Erzeuge mir Test-Scaffolding für die Schadenermittlung mit realistischen Vertrags- und Schadenskonstellationen aus dem KFZ-Bereich.
In einem solchen Szenario könnte ein LLM fachlich plausible Datenmuster über XDM anfordern und diese anschließend nutzen, um Testcode, Fixtures oder Beispieldaten für Testfälle vorzuschlagen.
Der Mehrwert läge dabei nicht nur im Komfort.
Tests könnten näher an realen fachlichen Konstellationen ausgerichtet werden als viele manuell erstellte Dummy-Szenarien.
Durch realistischere Testdaten in Unit Tests werden mögliche Fehler früher erkannt, die sonst mit gemockten oder synthetischen Daten nicht abgebildet oder bedacht wurden.
Gleichzeitig bliebe die zentrale Steuerung der Datenlogik, Modifikation und Bereitstellung in der dafür vorgesehenen Plattform verankert.
Gerade für Teams, die unter Zeitdruck arbeiten und trotzdem belastbare Tests benötigen, wäre das ein relevanter Schritt: weniger Reibung im Alltag, ohne die Kontrolle über Daten und Prozesse aus der Hand zu geben.
Der Prompt als neue Bestelloberfläche
Die vielleicht größte Veränderung wäre damit weniger technisch als organisatorisch und kulturell.
Bislang mussten sich Anwender oft an die Logik der Systeme anpassen: Masken verstehen, Parameter korrekt setzen, technische Strukturen kennen oder bestehende Prozesse im Detail nachvollziehen.
Das ist in stabilen Verfahren sinnvoll, erzeugt im Alltag aber auch Reibung.
Künftig könnte sich das System stärker an der Sprache des Anwenders orientieren.
- Der Prompt würde zur Bestelloberfläche.
- Das LLM würde zur Interaktionsschicht.
- MCP würde die Vermittlung übernehmen.
- XDM bliebe die Plattform, die die eigentliche Ausführung kontrolliert, regelbasiert steuert und nachvollziehbar macht.
Damit verschiebt sich nicht die fachliche oder technische Verantwortung, sondern vor allem die Art des Zugangs.
Fazit
Die Weiterentwicklung im Testdatenmanagement könnte weniger darin liegen, bestehende Plattformen zu ersetzen, sondern sie über natürlichere Interaktionsformen zugänglicher zu machen.
XDM bringt bereits viele Bausteine mit, auf denen ein solches Szenario aufsetzen kann: modellierte Anwendungen, Such- und Bereitstellungsmechanismen, Self-Service, Modifikation und Prozessintegration.
Neu wäre vor allem die Art der Interaktion.
Nicht mehr zuerst Formular und Parameterlogik, danach die Fachlichkeit — sondern zunächst die fachliche Beschreibung und darauf aufbauend die technische Ausführung.
Gerade für Entwickler, Tester und IT-Verantwortliche liegt darin ein nachvollziehbarer Nutzen: weniger Übersetzungsaufwand zwischen Fachbedarf und Systemlogik, ein direkterer Zugang zu geeigneten Testdaten und gleichzeitig eine kontrollierte operative Basis im Hintergrund.
