Im Prozess der Software-Entwicklung müssen immer wieder Tests durchgeführt werden. Dazu werden je nach Entwicklungsphase verschiedene Testdaten – von einzelnen Testfalldaten bis hin zu Massendaten – benötigt. Welche Möglichkeiten gibt es, diese Testdaten zu beschaffen? Im Folgenden werden wir uns drei Optionen anschauen.
1 Die manuelle Erzeugung von Testdaten
Diese Option haben die meisten Softwareentwickler bereits in der Praxis verwendet. Bevor sie ein neues Feature entwickeln, werden dabei fiktive Testdaten händisch in eine Datenbank getippt, die dann für die Tests verwendet werden. Diese manuelle Erzeugung von Testdaten ist allerdings recht zeitaufwendig und fehleranfällig. Es ist eine monotone Arbeit, die von der eigentlichen Entwicklung ablenkt.
Natürlich lassen sich hier auch keine komplexen Strukturen abbilden. Meist werden diese händischen Testfalldaten lediglich für einen konkreten Anwendungsfall entwickelt, der gerade bearbeitet wird und getestet werden soll.
In seinem Vortrag auf dem Navigate-Kongress zeichnet Software-Architekt Ulrich Lehner von LVM Versicherungen dazu ein treffendes Bild und vergleicht den Sachverhalt mit einem Autoscheinwerfer: „Beim Autoscheinwerfer wird nachts nur das ausgeleuchtet, was uns gerade beim Fahren interessiert, d.h. dass wir nur die Information zu Gesicht bekommen, die uns jetzt für die konkrete Streckenführung, für das konkrete Fahren interessieren. Die ganzen Informationen rundherum werden vom Scheinwerfer nicht erfasst oder höchstens durch Streulicht.“
Genauso fokussiert die manuelle Testdatenerzeugung auf den einen betrachteten Aspekt des Features. Alle Querverweise und weiteren Zusammenhänge können nicht berücksichtigt werden. Doch genau dieses Gesamtbild wäre wichtig, um ein Feature zu entwickeln und zur Produktionsreife zu führen. Aus diesem und den vorher genannten Gründen sind also manuell erzeugte Testdaten nicht der Idealfall.
2 Die synthetische Erzeugung von Testdaten
Synthetische Testdaten können automatisiert und in Masse produziert werden. Das ist weder zeitaufwendig noch für den Entwickler monoton, scheint also auf den ersten Blick eine gute Alternative zu sein, um an geeignete Testdaten zu kommen.
Aber auch dieses Verfahren hat diverse Nachteile:
a) Geringer Detailgrad synthetischer Testdaten
Angenommen, man betrachtet einen Kunden mit seinen Verträgen. Dann hängen damit viele Details zusammen. Zum Beispiel gibt es die Agentur, bei der die Verträge liegen. Und dort gibt es Mitarbeiter, die für den Vertragsabschluss Provision erhalten haben usw. Also: Kunde, Verträge, Agentur, Mitarbeiter, Provisionen … Solche detaillierten Zusammenhänge lassen sich in der Tiefe bei synthetischen Testdaten häufig nicht erzeugen.
b) Geringe Konsistenz synthetischer Testdaten
Selbst wenn zusammenhängende Daten und Ketten mit viel Aufwand erzeugt wurden, dann mangelt es meist an der Konsistenz. D. h., die Daten hängen zwar im betrachteten Teilbereich grundsätzlich zusammen, liefern aber im Gesamtkontext aller Daten kein konsistentes, in sich stimmiges Bild, wie es beispielsweise bei realen Kundendaten der Fall ist.
c) Geringe Diversifizierung synthetischer Testdaten
Ein weiterer Aspekt liegt in der geringen Diversifizierung: Meistens werden synthetische Daten für die Haupt-Anwendungsfälle erzeugt. Die außergewöhnlichen und selten vorkommenden Randfälle werden dabei meist nicht berücksichtigt. Gerade diese sind aber wichtig für das Testing, denn sie können in der Praxis zu großen Problemen führen.
d) Hohe Sterilität synthetischer Testdaten
Der Begriff „synthetisch“ impliziert bereits die Künstlichkeit solcher Testdaten. Es sind Daten aus der Retorte. Sie sind nicht gewachsen, haben keine Geschichte. Damit besitzen sie meist auch eine hohe Sterilität. Im Optimalfall entsprechen sie der zu erwartenden Datenkonsistenz des gegebenen Systems. Sie sind mustergültig, wie aus dem Ei gepellt, vergleichbar mit der klischeehaften Familie vom Werbeplakat. Doch die entscheidende Frage lautet: wie realistisch sind solche synthetischen Daten?
Natürlich, kann man bei der Herstellung synthetischer Daten versuchen, einige dieser Punkte zu optimieren. Vielleicht lassen sich der Detailgrad oder die Diversifizierung etwas erhöhen … Doch sind die Grenzen hierbei schnell erreicht: durch die Komplexität der gegebenen Strukturen und die Anzahl der Kombinationsmöglichkeiten steigt der Aufwand, um die Tiefe und Breite zu erhöhen, recht schnell exponentiell an.
3 Produktivdaten in Testdaten umwandeln
Die dritte Option nutzt reale Produktivdaten als Basis, um die benötigten Testdaten zu erzeugen. Dazu wird die Produktion 1:1 kopiert und hat damit automatisch den höchstmöglichen Realitäts- und Qualitätsgrad. Damit hätten sich die vorher beschriebenen Nachteile hinsichtlich Detailgrad, Konsistenz und Differenzierung unmittelbar erledigt. Außerdem haben die realen Daten eine echte Geschichte und damit geringe Sterilität.
Es handelt sich hier tatsächlich um „gelebte“ Daten. Vielleicht wurden sie früher einmal als IMS-Tabelle angelegt, sind dann im Db2 z/OS gelandet und dort jetzt ein Db2 LOB ... D.h. sie haben einen gewissen Lebenszyklus hinter sich. Und das sind im Endeffekt die qualitativ hochwertigen Testdaten, die zum realistischen Testing eines Features gebraucht werden.
Jetzt hat das Ganze einen Haken: die Anforderungen der Datenschutz Grundverordnung (DSGVO). Danach dürfen Daten einzig für den Zweck verwendet werden, für den sie originär erfasst wurden. Kundendaten dürfen z.B. ausschließlich dazu verwendet werden, das Vertragsverhältnis abzuwickeln und den Kunden zu betreuen und – wenn er eingewilligt hat – noch über neue Produkte zu informieren. Keinesfalls dürfen sie einfach kopiert und als Testdaten verwendet werden.
Allerdings dürfen die Daten dann verwendet werden, wenn sämtliche personenbezogenen Informationen daraus entfernt bzw. entfremdet wurden. Das geschieht über die sogenannte Pseudonymisierung. Softwarelösungen wie XDM aus der UBS Hainer TDM Suite bieten hier eine automatisierte Pseudonymisierung, die allen Anforderungen der DSGVO gerecht wird und doch alle oben angesprochenen Anforderungen an qualitativ hochwertige Testdaten erfüllt.
Haben Sie Fragen zu dieser Thematik? Gern demonstrieren wir unsere Lösungen anhand ihrer konkreten Anforderungen.
