“Es ist wieder Budget da. Es muss nur KI draufstehen.” - Richard Seidl
Testdatenmanagement erlebt gerade eine Renaissance. Natürlich getrieben durch KI und die Möglichkeiten, die man sich davon erhofft: bessere, passgenaue Testdaten, einfache Generierung, mühelose Verwaltung über Systemgrenzen hinweg. Da sprudelt es nur so vor Ideen, was alles möglich wird … oder wäre … oder naja vielleicht … hm.
Es gibt ja in der Softwareentwicklung ein paar Klassiker an Herausforderungen. Aber während wir z. B. jene um Releases (Pipelines) und Testumgebungen (Cloud) halbwegs gelöst haben, ist das mit Testdaten so eine Sache. Gerade in Applikationslandschaften mit vielen unterschiedlichen Systemen und Datenhaltungen arten daher Testdateninitiativen schnell einmal aus. Ist auch nicht einfach, denn die Herausforderungen sind mannigfaltig:
- Daten, Daten Daten – es sind einfach sehr viele. Unzählige Tabellen und Felder und dazu tausende, manchmal sogar Millionen, Datensätze. Die alle kreuz und quer verlinkt sind und in Verzeichnissen noch irgendwelche Import/Export-Daten enthalten.
- Kompatibilität – Jedes System hat sein eigenes Schema, seine eigene Datenorganisation, die nicht zwangsläufig zueinanderpasst. Eine saubere Datenarchitektur über Systemgrenzen hinweg ist nicht einfach. Unterschiedliche Zuständigkeiten bringen dann noch zusätzliche Komplexität rein.
- Synthetische vs. Echt-Daten – Synthetische Testdaten helfen mir ungemein bei meinen strukturierten Testfällen (Grenzwerte, ÄKs, etc.) – aber sind halt auch nicht Realität.
- Und sobald man an Echt-Daten mit all ihren Besonderheiten, Fehlern etc. geht, steht der Datenschutz vor der Tür: Ano- und Pseudonymisierung brauchen wiederum viel Energie und Zeit.
- Wollen wir noch einen draufsetzen? Dann müssen unsere Testdaten auch noch Historisierung und Zeitreisen abbilden. Yeah – Jackpot.
Die KI wirds scho richten, oder?
Aber alles gar kein Problem. Einfach alle Regeln, Anforderungen und Co in eine KI schmeißen und dann generieren wir uns systemübergreifend und fast in Echtzeit unsere Testdaten – ein Träumchen. Nur bin ich mir ziemlich sicher, dass das so einfach nicht funktioniert. Es gibt schon ein paar ganz schöne Ansätze zur Generierung und Verwaltung von Testdaten. Meine Beobachtung ist, dass hier aber ganz oft Symptombehandlung betrieben wird. Ich würde da lieber zwei andere Fragen in den Raum stellen.
Welche Daten brauche ich wirklich? (Und von diesen: welche brauche ich wirklich wirklich?) Nur weil wir alles speichern können, heißt das noch lange nicht, dass wir das müssen. Es ist so einfach ein Feld in einer Tabelle hinzuzufügen – die Auswirkungen können aber dramatisch sein. Also: Einfach mal weglassen und alle Strukturen löschen, die nicht benötigt werden. Eine (Test -)datenradikalkur !
Habe ich eine passende Datenarchitektur? Bei systemübergreifenden Architekturen sehe ich viele Schnittstellen und Abhängigkeiten, aber kaum ein Gesamtbild der Datenhalten, Datenflüsse und wo welche Daten sinnvoll abgelegt werden. Damit sie nicht redundant und zirkulär abgelegt werden. So wird langsam ein Schuh draus.
Und sind die Daten halbwegs ordentlich, dann überleg ich mir mal irgendwas mit KI 😉
Häufig gestellte Fragen
Warum gilt Testdatenmanagement als ungelöstes Problem, obwohl Releases und Testumgebungen längst automatisiert sind?
Für Releases gibt es Pipelines, für Testumgebungen die Cloud: Diese Klassiker der Softwareentwicklung sind halbwegs gelöst. Testdaten nicht. Sie hängen an gewachsenen Applikationslandschaften mit vielen Systemen und getrennten Datenhaltungen, und genau dort geraten Testdateninitiativen schnell außer Kontrolle. Das Problem ist weniger ein technisches Werkzeug als die Struktur der Daten selbst.
Was macht Testdaten in großen Systemlandschaften so aufwendig?
Die schiere Menge und ihre Verflechtung. Es sind unzählige Tabellen und Felder, dazu tausende bis Millionen Datensätze, die kreuz und quer verlinkt sind, ergänzt um Import- und Exportdaten in irgendwelchen Verzeichnissen. Dazu kommt die Kompatibilität: Jedes System bringt sein eigenes Schema und seine eigene Datenorganisation mit, und unterschiedliche Zuständigkeiten erhöhen die Komplexität zusätzlich.
Wann stoßen synthetische Testdaten an ihre Grenzen?
Synthetische Testdaten helfen enorm bei strukturierten Testfällen, etwa bei Grenzwerten oder Äquivalenzklassen. Sie sind aber nicht die Realität. Die Besonderheiten und Fehler, die in produktiven Beständen stecken, bilden sie nicht ab. Wer diese Effekte testen will, kommt um Echtdaten nicht herum, und damit um einen ganz anderen Aufwand.
Warum sind Echtdaten im Test kein einfacher Ausweg?
Sobald Echtdaten ins Spiel kommen, steht der Datenschutz vor der Tür. Anonymisierung und Pseudonymisierung kosten viel Energie und Zeit, und dieser Aufwand fällt nicht einmalig an. Der Gewinn an Realitätsnähe wird also mit einem dauerhaften Zusatzaufwand bezahlt, den man bei der Planung einer Testdateninitiative einkalkulieren sollte.
Warum lösen Werkzeuge zur Testdatengenerierung das Problem oft nicht?
Weil sie Symptome behandeln. Es gibt durchaus ansprechende Ansätze zur Generierung und Verwaltung von Testdaten, aber sie setzen an der falschen Stelle an, solange zwei vorgelagerte Fragen offen sind: Welche Daten braucht man wirklich, und existiert überhaupt eine passende Datenarchitektur? Erst danach lohnt der Blick auf Generierung, KI eingeschlossen.
Was bringt es, Datenstrukturen konsequent zu löschen?
Nur weil sich alles speichern lässt, muss man es nicht speichern. Ein Feld in einer Tabelle ist schnell hinzugefügt, die Auswirkungen können dramatisch sein: mehr Abhängigkeiten, mehr zu befüllende Testdaten, mehr Pflegeaufwand. Eine Radikalkur, bei der alle nicht benötigten Strukturen verschwinden, verkleinert das Testdatenproblem an der Wurzel.
Woran erkennt man, dass eine tragfähige Datenarchitektur fehlt?
An vielen Schnittstellen und Abhängigkeiten bei gleichzeitig fehlendem Gesamtbild. Wenn niemand sagen kann, welche Datenhaltungen es gibt, wie die Datenflüsse verlaufen und wo welche Daten sinnvollerweise liegen, entstehen redundante und zirkuläre Ablagen. Genau diese Struktur macht systemübergreifende Testdaten später so mühsam.
