News/Blog

19.11.2020

Wie Sie mit dem strategischen Einsatz von synthetischen Testdaten dauerhaft Ihre Aufwände im Softwaretest reduzieren

Wie Sie mit dem strategischen Einsatz von synthetischen Testdaten dauerhaft Ihre Aufwände im Softwaretest reduzieren [Bildnachweis: iStock.com/Ratana21]

In unseren letzten Beiträgen zum Thema Datenschutz und Testdaten hatten wir uns den folgenden Themen gewidmet:

Betrachten wir nun einmal die Aufwandsseite. Für aussagekräftige Tests werden Datensätze in realistischer Ausprägung benötigt. Einzelne Parameter können dabei nicht beliebig reduziert werden – beispielsweise Postleitzahlen beim Test für die Berechnung von Versicherungspolicen.

Die Schritte, die beim Umwandeln von Produktivdaten in brauchbare anonymisierte Testdaten nötig wären, sind im Wesentlichen folgende:

  1. Identifizieren und spezifizieren, welche Parameter für den Test gebraucht werden.
  2. Eliminieren direkter Personenbezüge in den Produktivdaten, wie z.B. Name, Kontonummer oder VIN. Dabei müssen Daten durch Token oder passende Stellvertreter ersetzt werden.
  3. Quasi-Identifikatoren erkennen. Dazu müssen die für den Test zu verwendenden Datensätze auf k-Anonymität und ℓ-Vielfalt geprüft werden.
  4. Quasi-Identifikatoren eliminieren.
  5. Suche und Auswahl der für den Test geeigneten Datensätze.
  6. Anpassen der ausgewählten Datensätze für den Test.

Schritt 1 ist in jedem Fall unabdingbare Voraussetzung: Es muss bekannt sein, was konkret getestet werden soll und welche Testdaten in welcher Ausprägung dafür benötigt werden. Die Schritte 2 - 4 erfordern eine zuverlässige Automatisierung - dies händisch zu tun, wäre eine Aufgabe für ein kombinatorisches Genie wie einen Schach-Großmeister. In den Schritten 5 und 6 steckt ein enormer Aufwand, der sich in der Regel nicht automatisieren lässt.

Man kann sich an dieser Stelle fragen, warum Schritt 5 nicht vor der Anonymisierung durchgeführt wird. Die Antwort ist einfach: Die Tester, die die Datensätze für die Nutzung im Test auswählen, arbeiten dann bereits mit personenbezogenen Daten, die entweder noch einen direkten Personenbezug oder mindestens noch Quasi-Identifikatoren enthalten. Zudem können sie später die Testdaten den Originaldaten wieder zuordnen. Damit sind diese nicht mehr anonym! Die Auswahl der Daten für den Test darf darum erst nach der Anonymisierung erfolgen.

In Schritt 6 müssen Testdaten unter Umständen ergänzt bzw. angepasst werden. Das für das Eliminieren von Quasi-Identifikatoren charakteristische teilweise Schwärzen von Feldern ist für eine Nutzung der Daten im Test nicht geeignet. Datenfeld-Kombinationen, die einen Quasi-Identifikator ergeben können, wie z.B. Automodell, Postleitzahl und Geburtsjahr im Falle einer Autoversicherung müssen durch im Format gültige und für den Test passende Stellvertreter ersetzt werden. Für den Test passend heißt, dass die Ersetzungen zum gleichen Testergebnis führen wie die (nicht veränderten) Originaldaten. Es ist nicht gesagt, dass in den anonymisierten Daten alle für den Test erforderlichen Testdaten vorhanden sind. Entweder, weil in den ursprünglichen Daten kein passender Datensatz enthalten war, oder passende Datensätze bei der Anonymisierung verändert werden mussten. Eine weitere Herausforderung ergibt sich, wenn identifizierte Testdaten mehrfach benötigt werden. Wenn zum Beispiel ein bestimmter Vertrag im Test einmal gekündigt, einmal geändert und einmal auf eine andere Person übertragen werden soll, müssten die passenden Datensätze nach der Migration ins Testsystem noch zusätzlich geklont werden.

Ein weiterer Aspekt ist das Problem der „Zeitdilatation“ bei migrierten Testdaten. Zwischen Aufsetzen des Testsystems bzw. Auswahl der Testdaten und der Durchführung der Tests dreht sich die Kalenderuhr weiter. Vertragsdaten wie Lieferzeitpunkte, Kündigungs- oder Mahnfristen laufen relativ zu den Testdaten im Testsystem ab. Für viele Tests werden jedoch Datensätze in einem konkret definierten Status benötigt.

Im Testsystem müssen dann „Zeitreisen“ durchgeführt werden, d.h. die Systemzeit des Testsystems muss allein wegen der Testdaten in die Vergangenheit oder in die Zukunft gedreht werden. Oder es müssen stets die neuesten Echt-Daten anonymisiert und ins Testsystem – unter Durchführung aller oben beschriebenen 6 Schritte – migriert werden. Beide Vorgehen sind mit erheblichem Aufwand verbunden.

Betrachten wir nun die für die Erzeugung passender rein synthetischer Testdaten notwendigen Schritte:

  1. Identifizieren und spezifizieren, welche Parameter für den Test gebraucht werden.
  2. Spezifikation in einen Testdatengenerator überführen, d.h. Erstellung der Testdatenanlagen.
  3. Generierung passender synthetischer Daten für den Test, immer dann, wenn getestet wird.

Schritt 1 stimmt mit dem Vorgehen bei der Anonymisierung von Echtdaten überein. Im Testdatengenerator werden die entsprechenden Testdatenanlagen erstellt und mit diesen automatisiert zum jeweiligen Testzeitpunkt passgenaue (neue) synthetische Testdaten generiert.

Die Nutzung synthetischer Testdaten hat neben dem geringeren Aufwand noch weitere Vorteile:

  • Die aufwändige Testdatensuche je Testdurchführung entfällt.
  • Die Testdaten sind immer aktuell und genau passend für den jeweiligen Testfall; Zeitdilatations-Effekte sind ausgeschlossen.
  • Testdatensätze müssen nicht geklont (und vorher dafür markiert) werden.
  • Alle erforderlichen Testfälle können durchgeführt werden, weil für alle Testfälle passende Testdaten in beliebiger Menge und Varianten, Testdaten mit Historie und für Grenzwerttests sowie auch ungültige Daten generiert werden können.
  • Bei Neueinführungen von Software können Tests auch schon vor der Migration der Altdaten in das neue System durchgeführt werden.

Fazit:

Bei einer professionellen Anonymisierung von Echtdaten für Testzwecke fallen gegenüber einer synthetischen Erzeugung von Testdaten neben der eigentlichen Anonymisierung regelmäßig zusätzliche manuelle Schritte an:

  • Geeignete Testdatensätze müssen ausgewählt werden.
  • Fehlende Testdatensätze müssen ergänzt werden.
  • Mehrfach benötigte Datensätze müssen identifiziert und geklont werden.

Eine Testdatenstrategie mit rein synthetischen Testdaten ist damit wesentlich effizienter und hat zudem den Vorteil, dass immer perfekt passende Testdaten für den Test verfügbar sind. Das spart wertvolle Zeit bei der Testdatenerstellung und reduziert damit den Gesamtaufwand für das Testen im Projekt bei gleichzeitiger Steigerung der Software-Qualität, weil alle erforderlichen Testkonstellationen durchgeführt werden können. Darüber hinaus ist das „DSGVO-Problem“ im Test auf elegante Weise gelöst.

Autor:
Christian Alexander Graf berät Unternehmen zu Teststrategien, Datenanalysen und IT-Sicherheit. Zusätzlich unterrichtet er Statistik und IT-Sicherheit u.a. an der DHBW in Mannheim.
Christian Alexander Graf ist außerdem Buchautor und hat etliche Fachartikel zu unterschiedlichen Themen rund um die Qualitätssicherung verfasst.

Co-Autorin:
Isabella Rieger ist Head of Sales and Business Development bei FMC GmbH und beschäftigt sich mit Software zur Erstellung von synthetischen Testdaten sowie für Testautomatisierung.


‹ zurück