Testest Du schon oder suchst Du noch nach geeigneten Testdaten?

In unseren Testautomatisierungsprojekten stellen wir immer wieder fest, dass fehlende, unvollständige oder inkonsistente Testdaten sowie rudimentär ausgebildetes Testdatenmanagement zu Problemen führen können. Zum einen ist die Suche nach geeigneten Testdaten mit viel Aufwand und Fachexpertise verbunden, die man anfangs nicht einem Automaten überlassen kann. Zum anderen ist eine zyklisch aus Produktivdaten gewonnene Testbasis zwangsläufig Änderungen unterworfen, welche nicht der eigenen Kontrolle unterliegen und somit zu teilweise ungewollten, schwer planbaren, aber unabwendbaren Anpassungen von automatischen Testsuites führen können.

Ein rudimentäres Testdatenmanagement (TDM) verzögert damit unter Umständen eine Erhöhung des Automatisierungsgrades, verursacht Konflikte zwischen Test- und Entwicklungsteams und erzeugt unnötig Zusatzaufwände. Dieser Beitrag soll sowohl Grundbausteine von TDM als auch Auswege aus diesem Dilemma aufzeigen.

Testdaten, nichts für Feiglinge!

In einem großen Kundenprojekt ereignet sich folgende Situation: Es soll ein sehr einfacher Testfall einer Produktsuche umgesetzt werden. Das Ergebnis soll im Anschluss Ausgangspunkt für verschiedene weitere fachliche Prüfungen sein. Insofern muss das Ergebnis der angestrebten Suche über eine gewisse Fachkomplexität und Historie an Daten verfügen. Der erfahrene Kundenmitarbeiter kennt natürlich viele Kriterien eines guten Ergebnisses implizit und ist so in der Lage, aussichtsreiche Kandidaten in den abgezogenen und nachträglich teil-anonymisierten Produktivdaten zu erspähen, obwohl der Testfall selber aufgrund der Verwendung sich ändernder Produktivdaten nicht beschreibt, wie genau man an diese Testdaten gelangt.

Ein Automat kann dieses Verhalten nur schwer nachstellen. Ein externer Dienstleister, der mit der Umsetzung einer Testautomatisierung betraut ist, hat dieses Wissen anfangs nur in den seltensten Fällen. Hier ergeben sich also gleich mehrere Problemstellungen. Produktionsdaten können sich verändern, ohne dass man davon Kenntnis erlangt, und darauf basierende Skripte können nach einer Aktualisierung der Testbasis z. B. aufgrund eines neuen Produktivdatenabzugs aus den unterschiedlichsten Gründen fehlschlagen. Entwickelt man flexiblere und für bestimmte Datenkonstellationen tolerante Testskripte und ergänzt damit weitere Geschäftslogik, um die verwendete Testbasis bei Testdurchführung zu analysieren und zu überprüfen, erkauft man sich dieses durch höhere Laufzeiten und steigende Aufwände in Erstellung und Wartung der Testsuite selber. Dabei existieren noch viele weitere Störquellen neben sich verändernden Produktivdaten wie z. B. Aktualisierung von Anonymisierungsregeln oder unsaubere Datenmigrationen. Gerade letztere Datenqualitätsmängel sind zwar für das Testmanagement durchaus interessant, aber bei der Automatisierung von Tests gänzlich unerwünscht.

Doch widmen wir uns zunächst einigen grundlegenden Überlegungen bzgl. Testdaten und deren Herkunft.

Wie können Testdaten bereitgestellt werden? Selber machen oder doch kopieren ?

Zur Bereitstellung von Testdaten gibt es eigentlich nur zwei Möglichkeiten:

1. Kopieren produktiver Daten, sogenanntes Cloning in Form eines i. d. R. vollständigen Produktivabzugs
2. Manuelles und/oder automatisches Generieren von Testdaten

Für den Punkt 1 trifft man gelegentlich auch ein selektives Cloning von Untermengen von Daten an (Subsetting). Dieses setzt i. d. R. aber Kenntnisse über die Geschäftslogik und/oder die interne Struktur der datenhaltenden Schicht voraus. Daher treffen wir in der Praxis wesentlich häufiger den Fall 1 an, in dem auf Basis von historischem Wissen und Erfahrung der Kundenmitarbeiter bekannt ist, welche Testdaten für weitere Qualitätssicherungsmaßnahmen geeignet sind. Der Vorteil dieser Art der Bereitstellung ist, dass bei Veränderung von Anforderungen, bei ungenau formulierten Anforderungen oder auch der Durchführung massiver Fachtests für lange Zeit ausreichend relevante Daten zur Verfügung stehen und diese sich aufgrund der hohen Anzahl nur langsam verbrauchen. Die Herstellung eines Produktionsabzugs ist natürlich aufwendig und wird daher nur selten durchgeführt, was der Aktualität der Testdaten schadet. Hinzu kommt, dass der benötigte Speicherplatz - gerade in Zeiten von DevOps und CI/CD - auf vielen lokalen und nur temporär existierenden Systemen (virtualisierte Systeme, Containersysteme wie DOCKER) zu groß ist, um diesen effizient zu handhaben. Die Folge ist nicht selten eine Reduktion auf zu wenige Testsysteme, auf denen sich im schlimmsten Fall verschiedene Projekte aufgrund von Testdatenüberschneidungen in die Quere kommen. Auch Restzweifel gegenüber Datenschutzfragen bestehen bei vollständigen Produktivkopien häufig noch.



Demgegenüber steht das manuelle bzw. automatische Generieren von passgenauen Testdaten. Synthetische Daten bieten viele Vorteile, vor allem, weil sie in Zeiten von Test Driven Design bei neuen Projekten häufig inhärent zusammen mit der Entwicklung des Codes aufgebaut werden. Zusätzlich erzielen diese gerade bei der Testabdeckung für Spezialfälle, Negativtests oder Tests neuer Datenstrukturen eine bessere Abdeckung als Produktivdaten. Selbstverständlich benötigt ein solches Vorgehen drastisch weniger Speicherplatz und man besitzt zu jeder Zeit die volle Kontrolle über alle erzeugten Daten. Dieses stellt für eine Automatisierung einen enormen Wert bzgl. der Wartungsfrequenz und Planbarkeit von Änderungen dar. Außerdem spart man sich das schwierige Thema Datenschutz gänzlich. Der Aufbau von synthetischen Testdaten ist allerdings auch mit Toolunterstützung nicht umsonst zu erhalten, sondern kostet Zeit und Geld. Auch muss man sich stets vor Augen halten, dass synthetische Daten nicht die Komplexität, Historie und Integrität von Produktionsdaten haben, die z. B. über 20 Jahre zu einem Versicherungskunden und seinen Vertragsunterlagen erfasst wurden. Der Aufwand ist aber gerade im Hinblick auf die Automatisierung lohnenswert, weil sich entsprechende Datenbanken oder Test-Container einfach handhaben lassen, um sie z. B. in den Ursprungszustand zurückzuversetzen, nachdem die Testdaten durch einen oder mehrere Testläufe verbraucht wurden. Damit eignen sie sich hervorragend für moderne DevOps-Techniken oder Continous Deployment/Continous Integration-Verfahren (CI/CD) und können einer Vielzahl von Anwendern aus einer zentralen Quelle zur Verfügung gestellt werden, vom Entwickler bis zur testenden Facheinheit.

Das Akzeptanzproblem: Überzeugungsarbeit ist gefragt!

Das größte Manko aus unserer Sicht bei synthetischen Testdaten ist leider ihre zu geringe Akzeptanz im Management und in Fachabteilungen. Einerseits erliegt man dem Glauben, dass synthetische Testdaten keine ausreichend produktive Qualität sicherstellen können, andererseits werden aber auch (häufig aus Budget-Gründen) nicht genügend Anstrengungen unternommen, ein Testdatenmanagement aufzubauen, welches in der Lage ist, synthetische Testdaten in hinreichender Qualität zur Verfügung zu stellen. An dieser Stelle wird dann gerne mit der Begründung Geld gespart, dass man ausreichend Testdaten ja schon aus dem Produktivsystem gewinnen könne, womit wir wieder am Anfang stehen und nicht aus der sich selbst erfüllenden Prophezeiung ausbrechen können. Es empfiehlt sich daher auf Basis unserer Erfahrung, die Einführung von Verbesserungsmaßnahmen im Bereich TDM mit Schulungen zu begleiten. So lassen sich die betroffenen Unternehmensbereiche durch entsprechende Maßnahmen sensibilisieren und werden mit den Datenschutz- und Testdatenproblematiken vertraut gemacht. Gleichzeitig kann man für einen sinnvollen Hybridansatz werben.

Das Beste aus beiden Welten: Warum nicht einen Hybrid?

In Abhängigkeit von Komplexität und Teststufe empfehlen wir als Best Case Scenario meist einen kundenindividuellen Mix aus automatisch/manuell generierten und produktiven Untermengen von Testdaten. Für letzteres Vorgehen existieren bereits viele Tools am Markt. Bei Eigenentwicklungen lässt sich in der Regel aus dem Datenbankmodell und/oder der Geschäftslogik ein geeigneter Kopiermechanismus umsetzen. Mit erfahrenen Mitarbeiter/innen lassen sich repräsentative Produktivdaten in einem Ausleseverfahren identifizieren und mittels besagter Tools kopieren.

Der große Vorteil ist, dass die Akzeptanz dieser Testbasis höher ist und man mit einem viel geringeren Umfang von produktiven Daten auskommt. Eine überschaubare Menge an Produktionsdaten bedeutet, dass man diese vollständig schützen kann und eventuell bestehende Restrisiken in der DSGVO-Konformität beseitigt. Alleine durch den selektiven Ansatz erfüllt man bereits den Anspruch der Datensparsamkeit. Das Prinzip der Datensparsamkeit verlangt von der verantwortlichen Stelle bereits im Vorfeld der Datenverarbeitung eine Ausrichtung des Datenverarbeitungsvorganges dahingehend, dass keine oder so wenig wie möglich personenbezogene Daten verarbeitet werden. Zusätzlich zieht es weitere Vorteile nach sich, wie z. B. die Vermeidung von ADV-Verträgen mit externen Dienstleistern (Auftragsdatenverarbeitungsvertrag). Auch vermeidet man das Risiko von Datenpannen auf Test- und Entwicklungssystemen. Dieses ist stärker verbreitet als man denkt. Während Produktivumgebungen häufig unter stärkster Beobachtung stehen, werden Entwicklungs- und Testsysteme oftmals weitaus weniger reglementiert als die Umgebung, in der Echtdaten verarbeitet werden. Häufig fehlt sogar eine Regelung, wer auf die Testdaten zugreifen darf, gänzlich. Werden Echtdaten in Testumgebungen als solche nicht erkannt, so kann es vorkommen, dass diese auf Messen in Vorführsystemen einsehbar sind, unverschlüsselt versendet oder nicht fristgerecht gelöscht werden.

Des Weiteren kann man so erzeugte bzw. gewonnene Testdaten insoweit besser kontrollieren und normalisieren, dass sie problemlos einer Automatisierung zugeführt werden können. Durch die Vereinheitlichung der Bereitstellung von Testdaten lassen sich automatisierte Teststrecken leichter bündeln, was wiederum DevOps und CI/CD-Methoden begünstigt. Auch manuelle Tests (Black-Box-Test) und Tester profitieren. Fachmitarbeiter und Tester werden durch die Komplexitätsreduzierung während der Tests unterstützt und können zielgerichteter Wissen aufbauen, welches wiederum positiv auf das Anforderungsmanagement rückwirkt.

Testdatenmanagement: Ein Prozess mit Potenzial!

Wie oben dargestellt, gibt es mehrere Handlungsfelder, die man im Testdatenmanagement abdecken möchte. Zum einen die nachweisbare Sicherstellung von Datenschutz und Informationssicherheit in nicht-produktiven Umgebungen, die Unterstützung und Optimierung von Testfällen und automatisierten Tests sowie die Optimierung von Kosten und Rüstzeiten für Testumgebungen. Dazu muss zum einen ein Management-Prozess für Testdaten etabliert werden, der von der Anforderungsanalyse bis zu deren Bereitstellung reicht, als auch eine geeignete Einführungsstrategie ersonnen werden. Hierbei ist neben der Festlegung der prozessualen Sicht auf den Lebenszyklus der Testdaten auch der organisatorische Rahmen zu betrachten, unter anderem Zuständigkeiten, Qualifikationen, Kommunikationskanäle, aber auch bestehende Richtlinien, Prozesse, Strukturen und Werkzeuge im Unternehmen. In der Regel beschreiten wir mit unseren Kunden gemeinsam einen iterativen Pfad und empfehlen eine mit dem Automatisierungsumfang parallelisierte Einführungsstrategie. Wichtig ist dabei, sich genügend Zeit für eine schrittweise und überlegte Einführung zu nehmen, auf deren Weg man möglichst viele Unternehmensbereiche, die mit Testdaten umgehen, mitnimmt. Nur so kann man maximal von der Einführung eines Testdatenmanagements profitieren.

Der richtige Mix macht sich bezahlt!

Auf diese Art und Weise konnte die viadee bei einem ihrer Kunden jede Abteilung mit einer eigenen Instanz einer Testdatenbank versorgen, den Testdatenverbrauch sehr individuell und schnell handhabbar gestalten sowie synthetische und produktive Testdatenanforderungen zentral in einer Masterdatenbank bündeln. Eine weitere Erfahrung aus der Praxis ist, eine Entscheidung für Toolunterstützung z. B. für Datenselektion oder Anonymisierung erst nach eingehender praktischer Eignungsprüfung und parallel zur Automatisierungsstrategie durchzuführen, um sie auf den optimalen Prozess anzupassen und nicht umgekehrt. Häufig ergeben sich aus der Realität andere Einstellungen im Hybridmix, als anfangs gedacht, die z. B. Vereinfachungen bei der Datenselektion erlauben, welche dann u. U. mit Bordmitteln einer Datenbank und ganz ohne extern zugekauftes Tool gelöst werden können.

Das Testdatenmanagement eröffnet also viele Vorteile. Die Anonymisierung selektiv ausgewählter Produktionsdaten für Entwicklungs- und Testumgebungen genügt gesetzlichen und internen Anforderungen an den Datenschutz und beugt Reputationsschäden vor. Speicher- und Rüstkosten lassen sich senken, da nicht länger Kopien der umfangreichen Produktivbestände vorgehalten werden müssen. Der Aufbau von Testumgebungen und die (manuellen als auch automatisierten) Tests selber werden schneller, weil sich die Infrastrukturen kurzfristiger bestücken lassen (Time-to-Market) und die Tests auf einer klaren Testbasis aufsetzen. Damit ist TDM ein wichtiger Baustein für moderne Entwicklungs- und Lieferformen (DevOps, CI/CD) und der damit einhergehenden Erhöhung des Automatisierungsgrades.

Sprechen Sie uns an! Die viadee unterstützt Sie gerne im Rahmen von Testautomatisierungsprojekten mit dem viadee Test Framework vTF oder auch ausschließlich zum Thema Testdatenmanagement (TDM). Reden Sie mit uns über Ihre Erfahrungen und den Mix, der für Sie am besten geeignet sein könnte.