Mit Testdaten sicher testen: So bleiben echte Daten geschützt

Pseudonymisierte Daten bleiben personenbezogene Daten, wenn sie mit Zusatzwissen wieder einer Person zugeordnet werden können. Unveränderte Echtdaten gehören deshalb nur in einen Test, wenn sich ein konkreter Fehler anders nicht untersuchen lässt und Rechtsgrundlage, Zugriff, Schutz sowie Löschung vorher geklärt sind.

Welche Testdaten passen zu welchem Zweck?

Die BfDI-Kurzposition zu personenbezogenen Daten bei Software-Entwicklung und -Tests empfiehlt genau diese Richtung: zuerst nicht personenbezogene oder anonyme Daten, danach pseudonymisierte Daten und unveränderte Echtdaten erst als letzte Möglichkeit. Die DSGVO verlangt zudem, personenbezogene Daten auf das notwendige Maß zu beschränken.

Ich halte deshalb die Frage „Wie maskieren wir unsere Produktionsdaten?“ oft für zu früh. Die bessere erste Frage lautet: Welche Eigenschaft muss dieser Test beweisen? Um ein Namensfeld mit 100 Zeichen zu prüfen, brauchen Sie keinen echten Namen, sondern einen künstlichen Wert mit 100 Zeichen.

Synthetisch, maskiert, pseudonymisiert oder anonym?

Synthetische Testdaten werden neu erzeugt und beziehen sich nicht auf echte Personen. „Testperson 017“ und „[email protected]“ sind einfache Beispiele. example.com ist von der IANA für Beispiele reserviert.

Maskierte Daten wurden sichtbar verändert, etwa durch Sternchen. Das erschwert die Einsicht, beweist aber keine Anonymität. Seltene Merkmale, Freitext oder andere Felder können eine Person weiterhin verraten.

Pseudonymisierte Daten ersetzen direkte Merkmale durch Kennungen oder Token. Eine getrennte Zuordnungstabelle oder ein Schlüssel kann die Verbindung zur Person wiederherstellen. Der Europäische Datenschutzausschuss stellt deshalb klar: Solche Daten bleiben personenbezogen.

Anonyme Daten lassen sich einer Person nicht mehr zuordnen. Nur Name und E-Mail zu löschen reicht dafür nicht automatisch. NIST weist darauf hin, dass einfache Maskierungswerkzeuge nicht zwingend eine ausreichende De-Identifizierung leisten. Das Wiedererkennungsrisiko muss zum Datensatz und Nutzungskontext passen.

Echtdaten sind unveränderte Kunden-, Mitarbeiter-, Nutzungs- oder Zahlungsdaten. Ein Testsystem macht sie nicht weniger schützenswert.

Sichere Testdaten in sechs Schritten erstellen

1. Schreiben Sie die Testfrage auf

Ein Satz genügt: „Wir prüfen, ob der Import doppelte Kundennummern erkennt.“ Daraus folgen die nötigen Felder und Fälle. Alles andere bleibt draußen.

2. Bauen Sie einen Vier-Körbe-Datensatz

Für kleine Teams ist ein geplanter Satz oft wertvoller als tausend zufällige Zeilen:

1. Normalfälle: gültige, häufige Eingaben.
2. Grenzfälle: leer, sehr kurz, sehr lang, null, zukünftiges Datum, Umlaute oder Bindestriche.
3. Fehlerfälle: falsches Format, fehlendes Pflichtfeld, unbekannte ID oder Dublette.
4. Beziehungen: ein Kunde mit mehreren Aufträgen, ein Auftrag ohne Position oder zwei Datensätze mit derselben Referenz.

Die BfDI nennt fehlende Attribute und ungewöhnlich lange Namen ausdrücklich als Tests ohne nötigen Personenbezug. Der Vier-Körbe-Ansatz ist unsere redaktionelle Arbeitshilfe daraus: Er zwingt ein Team, nicht nur den glücklichen Weg zu prüfen.

Jeder Datensatz hat damit einen Zweck und ein erwartetes Ergebnis.

3. Trennen Sie die Testumgebung wirklich

Eine andere URL allein genügt nicht. Trennen Sie Datenbank oder Mandant, Konten und Rollen, API-Schlüssel, Dateiablagen, Logs sowie ausgehende E-Mails, SMS und Webhooks.

OWASP beschreibt eine UAT-Umgebung als produktionsnah, aber mit Testdaten statt echten Daten. Bei verbundenen Diensten hilft deren Sandbox. Stripe verlangt etwa Test-API-Schlüssel und warnt ausdrücklich vor realen Kartendaten im Test. Unser Guide API einfach erklärt zeigt, wo Schlüssel, Webhooks und Datenflüsse liegen.

4. Entschärfen Sie Nebenwirkungen

• E-Mails gehen an ein Testpostfach oder einen Mail-Catcher.
• Echter SMS-Versand bleibt aus.
• Zahlungen nutzen Sandbox-Konten und Testschlüssel.
• Webhooks gehen nur an Testendpunkte.
• Oberfläche und Exporte tragen sichtbar den Hinweis TEST.
• Nicht benötigte Verbindungen zum Produktivsystem sind gesperrt.

5. Suchen Sie nach echten Datenresten

Prüfen Sie auch Freitext, Anhänge, Logauszüge, Screenshots, Exporte und automatisch kopierte Profile. Suchen Sie stichprobenartig nach realen Domains, Kundennummern und Namen. Bei pseudonymisierten Daten bleiben Schlüssel und Zuordnungstabellen getrennt.

6. Legen Sie Ende und Rückweg fest

Bestimmen Sie, wer freigibt, wie lange Daten bleiben, wann Konten und Schlüssel gelöscht oder gedreht werden und wie Änderungen zurückgenommen werden.

Ein Backup kann bei Änderungen wichtig sein, macht Echtdaten im Test aber nicht sicher. Es löst ein anderes Problem: Wiederherstellung nach Löschung oder Fehlkonfiguration. Die Unterschiede erklärt unser Guide zu SaaS-Backups und Restore-Tests.

Wann dürfen Echtdaten überhaupt in einen Test?

Eine pauschale Freigabe wäre unseriös. Wenn synthetische, anonyme und pseudonymisierte Daten nicht ausreichen, beantworten Sie vor einer Echtdatenkopie schriftlich:

1. Welcher konkrete Fehler lässt sich anders nicht reproduzieren?
2. Welche Rechtsgrundlage und welcher Zweck decken die Testverarbeitung?
3. Reicht eine kleine, gefilterte Teilmenge?
4. Können direkte Merkmale vorher pseudonymisiert werden?
5. Wer darf zugreifen, und werden Zugriffe protokolliert?
6. Sind Umgebung und Übertragung gleichwertig geschützt?
7. Wann werden Daten, Logs, Exporte und lokale Kopien gelöscht?
8. Müssen Datenschutzbeauftragte, Informationssicherheit oder Kunden einbezogen werden?

Fehlt eine klare Antwort, sollte die Kopie warten. Besonders sensible Daten, freie Notizen und produktive Zugangsdaten gehören nicht beiläufig in Tickets, Chats oder Entwicklergeräte.

Typische Fehler

• Nur Namen und E-Mails ersetzen, aber Notizen oder seltene Merkmale behalten.
• Eine vollständige Datenbank kopieren, obwohl fünf Datensätze genügen.
• Test- und Live-Schlüssel in derselben Konfiguration mischen.
• Reale Empfänger hinter einem „Testmodus“ erreichbar lassen.
• Screenshots und Logs als harmlos behandeln.
• Testdaten nie löschen, weil die Umgebung „intern“ ist.
• Nur Normalfälle testen.
• Zufällige Domains erfinden, die real existieren könnten.

Checkliste vor dem Start

• Der Testzweck steht in einem Satz.
• Jeder Datensatz gehört zu einem konkreten Testfall.
• Vollständig synthetische Daten wurden zuerst geprüft.
• Pseudonymisierte Daten werden wie personenbezogene Daten geschützt.
• Live-Konten, Live-Schlüssel und reale Empfänger sind getrennt.
• E-Mail, SMS, Zahlung und Webhooks können keine reale Wirkung auslösen.
• Freitext, Logs, Anhänge und Exporte wurden mitgeprüft.
• Zugriff, Aufbewahrung und Löschung sind festgelegt.
• Jede Echtdaten-Ausnahme ist begründet und freigegeben.
• Für jeden wichtigen Test ist das erwartete Ergebnis bekannt.

Häufige Fragen

Reicht es, Namen und E-Mail-Adressen zu ersetzen?

Oft nein. Ort, Datum, Auftrag, seltenes Merkmal oder Freitext können zusammen eine Person erkennbar machen. Prüfen Sie den ganzen Datensatz und seinen Kontext.

Sind synthetische Daten automatisch gute Testdaten?

Nein. Sie vermeiden Personenbezug, können aber fachlich schlecht sein. Ein Satz nur aus einfachen Standardwerten übersieht Grenz- und Fehlerfälle.

Ist eine Sandbox dasselbe wie Testdaten?

Nein. Die Sandbox ist der getrennte Übungsraum; Testdaten sind das Material darin. Für Zahlungen oder Nachrichten brauchen Sie meist beides.

Darf ich Produktionsdaten anonymisieren und dann testen?

Das kann möglich sein, doch schon die Anonymisierung verarbeitet zunächst personenbezogene Daten. Außerdem anonymisiert kein einzelnes Verfahren jeden Datensatz automatisch sicher. Rechtsgrundlage, Zweck und Wiedererkennungsrisiko müssen zum Einzelfall passen.

Braucht ein kleines Team ein Testdaten-Tool?

Nicht zwingend. Für überschaubare Abläufe reichen oft gepflegte Beispieldateien und ein kleines Erzeugungsskript. Ein Werkzeug lohnt sich bei großen Mengen, stabilen Beziehungen oder nachweisbaren Transformationsregeln.

Fazit

Sicheres Testen beginnt nicht mit einem teuren Tool, sondern mit der Frage: Welche kleinste künstliche Datenmenge beweist, dass der Ablauf funktioniert? Danach folgen getrennte Umgebung, entschärfte Nebenwirkungen, klare Zugriffe und ein Löschdatum.

Für die meisten kleinen Teams ist ein Vier-Körbe-Datensatz aus Normal-, Grenz-, Fehler- und Beziehungsfällen der beste Start. Echtdaten sind kein Qualitätsmerkmal. Sie sind zusätzliche Verantwortung und sollten die Ausnahme bleiben.