Viele Testprobleme sind in Wahrheit Testdatenprobleme. Ein Test schlägt fehl, weil ein Kundenkonto fehlt, ein anderes Team die Daten verändert hat oder die Testumgebung seit Monaten nicht aktualisiert wurde. Dazu kommt die Frage, ob echte Kundendaten überhaupt in der Testumgebung liegen dürfen. Testdatenmanagement sorgt dafür, dass die richtigen Daten zur richtigen Zeit bereitstehen, und zwar so, dass Tests verlässlich und datenschutzkonform bleiben. Dieser Artikel zeigt, welche Arten von Testdaten es gibt, worauf Sie beim Datenschutz achten müssen und wie Sie eine Testdatenstrategie in fünf Schritten aufbauen.
Testdatenmanagement umfasst alles, was mit den Daten für Softwaretests zu tun hat: den Bedarf ermitteln, Testdaten erzeugen oder beschaffen, sie in den Testumgebungen bereitstellen, aktuell halten und am Ende wieder löschen. Testdaten sind dabei nicht nur Eingabewerte in einem Formular, sondern auch der Datenbestand, auf dem ein Test aufsetzt: Kundenkonten, Verträge, Produkte, Bestellungen oder Stammdaten aus angebundenen Systemen.
Wie mit Testdaten grundsätzlich umgegangen wird, gehört in die Teststrategie. Welche konkreten Daten ein einzelner Test braucht, steht im Testfall. Testdatenmanagement verbindet beide Ebenen und sorgt dafür, dass die Vorgaben im Projektalltag tatsächlich umgesetzt werden.
In vielen Projekten bekommt das Thema erst Aufmerksamkeit, wenn es bremst. Typische Anzeichen:
Es gibt nicht die eine richtige Quelle für Testdaten. In der Praxis werden mehrere Arten kombiniert, je nach Teststufe und Risiko.
Synthetische Daten werden künstlich erzeugt, zum Beispiel per Skript, mit einem Datengenerator oder über die Schnittstellen der Anwendung selbst. Sie enthalten keine echten Personendaten, lassen sich gezielt für Grenzwerte und Sonderfälle anlegen und beliebig oft neu erzeugen. Ihre Grenze: Sie sind nur so realistisch, wie sie modelliert wurden. Ungewöhnliche Konstellationen aus jahrelang gewachsenen Altdaten fehlen oft.
Hier wird ein Abzug der Produktionsdaten so verändert, dass keine Rückschlüsse auf echte Personen mehr möglich sind: Namen, Adressen, Kontonummern oder E-Mail-Adressen werden ersetzt, ohne Format und fachliche Zusammenhänge zu zerstören. Der Vorteil ist die realistische Datenvielfalt. Der Aufwand liegt in einer Maskierung, die wirklich wirksam ist und zusammengehörige Daten über mehrere Systeme hinweg konsistent hält.
Statt einer vollständigen Kopie wird nur ein fachlich zusammenhängender Ausschnitt übernommen, etwa ausgewählte Kunden mit allen zugehörigen Verträgen und Buchungen. Das spart Speicher und Ladezeit und ist meist mit Maskierung kombiniert.
Für einzelne Fachtests, etwa in der Abnahme, legen Tester Daten oft direkt über die Oberfläche an. Das ist flexibel, aber schwer reproduzierbar. Manuell angelegte Daten sollten deshalb dokumentiert oder später durch Skripte ersetzt werden.
Enthalten Produktionsdaten personenbezogene Daten, gilt die DSGVO auch in der Testumgebung. Eine unveränderte Kopie echter Kundendaten in eine Testumgebung ist daher in der Regel problematisch, zumal dort meist mehr Personen Zugriff haben und die Schutzmaßnahmen oft schwächer sind als in der Produktion.
Wichtig ist der Unterschied zwischen Anonymisierung und Pseudonymisierung. Pseudonymisierte Daten lassen sich mit Zusatzwissen wieder einer Person zuordnen und bleiben damit personenbezogen. Erst wirksam anonymisierte Daten fallen nicht mehr unter die DSGVO. Für die Praxis heißt das:
Diese Hinweise ersetzen keine Rechtsberatung, zeigen aber, wo im Projekt die Entscheidungen fallen müssen.
Gehen Sie von den Testfällen und Testszenarien aus: Welche Datenkonstellationen werden gebraucht? Für einen Webshop etwa Neukunden, Bestandskunden mit offener Rechnung, gesperrte Konten und Artikel ohne Lagerbestand. Diese Liste ist die Grundlage für alles Weitere.
Für Komponenten- und Integrationstests reichen meist synthetische Daten. Für System- und Abnahmetests ist oft eine realistischere Datenbasis nötig, dann mit anonymisierten Produktionsdaten. Für Lasttests zählt vor allem eine produktionsnahe Datenmenge.
Testdaten, die per Skript oder über Schnittstellen erzeugt werden, stehen in Minuten bereit statt nach Tagen. Halten Sie diese Skripte wie Code unter Versionskontrolle, damit sie mit der Anwendung mitwachsen.
Legen Sie fest, welche Daten wem gehören und wie ein definierter Ausgangszustand wiederhergestellt wird, etwa durch Zurücksetzen der Datenbank vor einem Testlauf oder durch eigene Datensätze pro Team. So bleiben Ergebnisse wiederholbar.
Testdaten veralten: Datenmodelle ändern sich, neue Produkte kommen hinzu. Benennen Sie eine verantwortliche Person, planen Sie regelmäßige Aktualisierungen und löschen Sie Daten, die nicht mehr gebraucht werden. Im Projekt ist das eine typische Aufgabe des Testmanagements.
Für die Testautomatisierung sind stabile Testdaten Voraussetzung. Bewährt hat sich, dass jeder automatisierte Test seine Daten selbst anlegt, zum Beispiel über eine API, und nach dem Lauf wieder entfernt. Tests werden so unabhängig voneinander und lassen sich parallel ausführen. Wo das nicht möglich ist, hilft ein fester Grundbestand, der vor jedem Lauf zurückgesetzt wird. Gerade bei Regressionstests, die vor jedem Release laufen, zahlt sich das aus: Fehlschläge zeigen dann echte Fehler und keine Datenprobleme.
In Scrum-Teams sollte die Frage nach den Testdaten schon im Refinement gestellt werden: Welche Daten braucht diese User Story, und gibt es sie bereits? Wer das erst im Sprint klärt, verliert dort Zeit. Hilfreich ist, die Bereitstellung der benötigten Testdaten in die Definition of Done aufzunehmen. Mehr zum Testen im Sprint lesen Sie im Artikel Agiles Testen in Scrum.
Gutes Testdatenmanagement fällt kaum auf, schlechtes dafür umso mehr. Wer den Datenbedarf aus den Tests ableitet, je Teststufe die passende Quelle wählt, die Bereitstellung automatisiert und den Datenschutz von Anfang an mitdenkt, bekommt wiederholbare Tests, kürzere Wartezeiten und weniger Diskussionen über die Frage, ob ein Fehler im Code oder in den Daten liegt.
Testdatenmanagement umfasst Planung, Erstellung, Bereitstellung, Pflege und Löschung der Daten, die für Softwaretests gebraucht werden. Ziel ist, dass jede Teststufe zur richtigen Zeit passende, aktuelle und datenschutzkonforme Testdaten hat, ohne dass Tests sich gegenseitig stören.
Enthalten Produktionsdaten personenbezogene Daten, gilt auch im Test die DSGVO. Eine unveränderte Kopie in eine Testumgebung ist deshalb in der Regel problematisch. Üblich sind synthetische Daten oder Produktionsdaten, die vorher wirksam anonymisiert oder maskiert werden. Pseudonymisierte Daten bleiben personenbezogen. Das konkrete Vorgehen sollte mit dem Datenschutzbeauftragten abgestimmt werden.
Synthetische Testdaten werden künstlich erzeugt, etwa per Skript, Generator oder über die Schnittstellen der Anwendung. Sie enthalten keine echten Personendaten, lassen sich gezielt für Grenzwerte und Sonderfälle anlegen und sind beliebig reproduzierbar. Ihr Nachteil: Sie bilden die Vielfalt echter Daten nur so gut ab, wie sie modelliert wurden.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihre Testumgebungen und Testdaten und zeigen, wo Tests verlässlicher werden können.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung und Testmanagement in Hamburg →
Passend dazu: Teststrategie: Inhalte, Beispiel und Vorgehen →