Testdaten aus Produktion: Für und Wider

Wenn eine Software-Applikation getestet werden soll, braucht man in der Regel zuverlässige Testdaten. In jedem Projekt kommt, spätestens bei der Frage welche Testdaten für die Testfälle zur Verfügung stehen, die Idee auf, diese aus der Produktion zu nehmen. Dieser Artikel erzählt, woran Sie denken sollten, wenn Sie zum Testen Daten aus der Produktion nehmen wollen bzw. sollen. Die Grundlage stammt nicht aus dem akademischen Bereich, sondern aus meiner 30-jährigen Erfahrung im Testmanagement aus real existierenden Projekten und Wartungsmaßnahmen.

Vorteile der Produktionsdaten für Tests

Es gibt unverkennbare Vorteile, wenn man Daten aus der Produktion nimmt:

Sie existieren
Sie sind realistisch
Sie sind konsistent (obwohl manchmal die Relationen zwischen den Daten nicht bekannt sind)
Es gibt Historien (Daten im Zeitverlauf)

Nachteile bei der Verwendung von Produktionsdaten

Nun muss man die Nachteile dagegenhalten:

Fehlende Zuordnung von Daten zum Testfall

Es muss Zeit investiert werden für die Suche nach passenden Testdaten für den einen Testfall, bzw. für die entsprechende Prüfreihe an Testfällen.

Zu viele/zu wenige Daten vorhanden

Wenn es zu viele Daten aus dem Produktivsystem gibt, kann die Testumgebung u.U. mit diesen nicht zurechtkommen, da die Testumgebung anders, meistens schwächer, ausgelegt ist.

Bei neuen Produkten könnten aus der Produktion zu wenig Daten kommen, um alle Testszenarien abdecken zu können.

Zu viele gleiche Daten

Die aus Produktion abgeholte Datenmenge kann sehr groß sein. Unter Anwendung der Äquivalenzklassenanalyse kann aber festgestellt werden, dass die Daten nicht ausreichend sind, d. h. zum Test benötigte Daten stehen nicht oder nicht ausreichend zur Verfügung. Beispiel: Bisher war das Geschäft auf den Binnenmarkt beschränkt, nun soll auch Auslandsgeschäft getätigt werden. Es fehlen (ausreichend) Daten zu Geschäften mit Fremdwährung.

Datenschutz

Zur Einhaltung des Datenschutzes (DSGVO) können Daten aus produktiven Beständen unter Zuhilfenahme von Pseudonymisierung, oder der Anonymisierung der Daten, verwendet werden.

a) Wenn zu wenige Attribute anonymisiert werden, können die zur Nutzung vorgesehenen, personenbezogenen Daten über weitere vorhandene Attribute schnell identifiziert werden.

b) Wenn zu viele Attribute anonymisiert werden, kann der gewünschte Datensatz unbrauchbar werden, z. B. der Ort kann für die Berechnung einer Versicherungsprämie entscheidend sein.

c) Wenn das Format der Rohdaten keine eindeutige Anonymisierung zulässt kann ein Buchstaben-/Zahlensalat entstehen. In diesem Fall verzichtet man am besten auf Produktionsdaten und nimmt automatisch/synthetisch erzeugte Daten für die Testfalldurchführung.

Das richtige Gleichgewicht von (a) und (b) findet man in der Literatur z. B. unter dem Stichwort k-Anonymität (ein formelles Datenschutzmodell). Auf alle Fälle ist die Daten-Anonymisierung zur datenschutzkonformen Weiterverwendung in Softwaretests mit Aufwand verbunden, der berücksichtigt werden muss.

d) Für die Pseudonymisierung und Anonymisierung muss bei allen Datenquellen der gleiche Algorithmus verwendet werden, sonst entstehen Inkonsistenzen.

Übertragen aus der Produktion

Einige Produktionssysteme sind „gehärtet“; Zugang zu einem (Teil-)Datenabzug ist mit hohen Hürden verbunden, d. h. die benötigten Daten können nur mit hohem Aufwand gewonnen werden.

Daten aus allen beteiligten Systemen

Besteht die Testumgebung aus mehreren Systemen, die auch eigene Datenhaltung haben, kann es bei dem Datenabzug zu Inkonsistenzen kommen. Dies geschieht, wenn die Daten nicht von allen relevanten Systemen entnommen werden können, z. B. im Abzug aus der Produktion des CRMs ist der Kunde ein Premium-Kunde, aber nach den Testdaten im Bestellwesen hat er noch nie etwas gekauft. Wenn Regeln in Ursprungsdatenbanken hinterlegt sind, kann dies zu anderen Ergebnissen führen als erwartet.

Für neue Anforderung keine Daten

Es liegt auf der Hand, wenn neue Anforderungen in Software aufgenommen werden, dann können u.U. in Produktion keine Daten dazu vorliegen.

"Leichen"/"Zombies" (z.B. 4-stellige PLZ, Missbrauch von Datenfeldeingaben)

In der Produktion sammelt sich auch sehr viel „Müll“ an. Fehler entstammen nicht zwangsläufig der Software, sondern können auch an der schlechten Datenqualität aus der Produktion liegen. Z. B. 4-stellige PLZ können plötzlich Fehler werfen, da eine Prüfungsroutine falsche PLZ feststellen würde. Ein ähnlicher Fall ist das X, welches auch bei 5-stelligen PLZ für verstorbene Personen eingesetzt wurde. Damit bestehen die PLZ nicht mehr nur aus Ziffern, was im Test unerwartete Fehler verursacht.

Kostenpflichtige Produktionsdaten

Es können an Produktionsdaten Kosten hängen, (z. B. Lizenzen) und bei Verwendung in einer anderen Umgebung anfallen.

Spezialfall KI: Daten schon bekannt

Die KI hat in der Produktion diese Daten schon gelernt. Würde man diese KI beim Test die Daten vorsetzen würde ein anderer Lerneffekt eintreten, als wenn die KI diese Daten noch nicht erhalten hätte. Im KI-Umfeld wird bzgl. Testdaten noch einiges neues entstehen.

Was muss weiter beachtet werden

Werden die Daten nur einmal oder regelmäßig bereitgestellt? Wenn einmal, dann müssen die Daten auch gepflegt werden.

Wann stehen die Daten zur Verfügung? Können z. B. bei Ultimo weitere Abzüge aus der Produktion gezogen werden?

Sind diese Daten für Regressionstests geeignet bzw. könnten diese Daten zurückgesetzt werden?

Können neue Daten den laufenden Tests/Teststufen hinzugefügt werden?

Fazit: Wenn Daten aus der Produktion genommen werden sollen, muss man sich den genauen Nutzen und den zu erwartenden Aufwand in die Überlegung einfließen lassen.

Autor: Wolfgang Schmidt

Bild: Lars Kienle, Unsplash