测试数据管理将主宰世界

Ausgangslage

Wem kommen folgende Situationen bekannt vor.

Manuelles Testing

Es stehe eine neue Testiteration an. Damit ich alle Tests durchführen kann, benötige ich gewisse Testdaten-Konstellationen, z.B. Kunden in verschiedenen Status (prospect, active, former,…). Somit geht die (teilweise lange) Suche nach passenden Testdaten los. Erst nachdem ich die passenden Testdaten gefunden habe, kann die Testiteration starten. Der Aufwand für die Suche nach passenden Testdaten reduziert somit die verfügbare Zeit für das Testing.

Automatisiertes Testing

Nach einem neuen Deployment werden die automatisierten Regressionstests gestartet. Das Resultat zeigt das 20% aller Testfälle fehlgeschlagen sind. Ich denke nur What the f*** und beginne mit der Analyse. Dabei stellt sich heraus, dass die Tests aufgrund falsch konfigurierter Stammdaten oder fehlenden Daten nicht ausgeführt werden konnten (Stichworte false-negative, false-positive). Ich schaue auf die Uhr und stelle fest, dass ich nun 1 h damit verbracht habe um herauszufinden, dass die Testdaten (mal wieder) an den fehlschlagenden Tests schuld sind (z.B. 20 Tests * 3 min Analyse = 60 min).

Wer sich in diesen Situationen wiedererkennt denkt nur: „Testdatenmanagement will rule the world“.

Problemstellung

Machen wir nun einen Schritt zurück und analysieren die möglichen Ursachen für Testdatenprobleme. Ich kann die Fehlerursachen und Probleme in meinem „Testing-Leben“ in folgende Kategorien klassifizieren. (Hinweis: Es ist keine abschliessende Liste und die Reihenfolgen spiegelt keine Priorität/Wichtigkeit wider):

• Produktive Daten
• Komplexität der benötigten Testdaten
• Umfang der Testdaten
• Begrenzte Lebensdauer der Testdaten (Testdaten können altern und verbraucht werden)
• Testdaten sind Umgebungsgebunden
• Notwendigkeit von Zeitreisen
• Gesetzliche-, branchenspezifische- und firmeninterne Vorgaben
• Bereitstellung der Testdaten

Schauen wir uns die Punkte im Detail an:

Ein Testing (insbesondere Testautomatisierung) anhand von produktiven Daten zu implementieren ist aus meiner Sicht zum scheitern verurteilt. Die produktiven Daten unterliegen i.d.R. einer begrenzten Lebensdauer (s.u.). Zudem ist es laut DSGVO (engl. GDPR) nicht erlaubt mit produktiven Daten zu testen (s.u.). Daher sollte das Testing auf synthetischen und/oder anonymisierte Daten aufgebaut werden.

Die Komplexität der benötigten Testdaten bezieht sich in erster Linie darauf, dass die Testdaten so produktionsnah wie möglich sein sollten. Beispielsweise werden für das Testing einer Reporting Funktionalität oder einer Historisierung viele unterschiedliche Daten benötigt. Dies kann sehr komplex in der Nachbildung mit synthetischen Testendaten sein. Hingegen ist zur Überprüfung einer Änderungsfunktionalität z.B. einer Adresse, die Nachbildung mit synthetische Testdaten weniger komplex. Der Aufwand für die Definition qualitativ hochwertiger, produktionsnaher synthetischer Testdaten darf nicht unterschätzt werden!!!

Der Umfang der Testdaten wird meistens in Zusammenhang mit der Testart betrachtet. Beispielsweise werden für Performance Tests (Non-Functional-Tests) viele Testdaten benötigt, dafür nur wenige Testdatenkonstellationen. Für einen Regressionstest hingegen werden sehr viele unterschiedliche Testdatenkonstellationen in geringer Menge benötigt.

Die begrenzte Lebensdauer der Testdaten ist aus meiner Sicht einer der grosses und wichtige Herausforderung für eine stabile Testautomatisierung. Es reicht nicht die Testdaten einmalig zu erstellen und bei jeder Testausführung wiederzuverwenden. Die Testdaten werden bei der Testausführung verbraucht und/oder unterliegen einer Alterung. Beispielsweise wenn im Testfall ein Kunde vom Status „prospect“ auf dem Status „active“ geändert wurde, kann dieser Testfall mit dem gleichen Kunden nicht mehr ausgeführt werden.

Das die Testdaten Umgebungs-Abhängig ist selbsterklärend, d.h. es ist nicht aussreichend, die Testdaten einmalig auf einer Umgebung z.B. Abnahme-Umgebung zu erstellen. Die Testdaten müssen auf allen Umgebungen erstellt werden, auf welcher Tests ausgeführt werden.

Zeitreisen von Testdaten können notwendig sein, wenn Funktionalität basierend auf einem gewissen Datum getestet werden sollen. Im Banken-Umfeld wären das z.B. die Monats- oder Jahresendverarbeitung.

Vorgaben für die Testdaten, seien es gesetzliche, branchenspezifische oder firmeninterne Vorgaben spielen eine zentrale Rolle. Die Testdaten müssen diesen Vorgaben entsprechen. Dies trifft insbesondere dann zu, wenn das DSGVO zur Anwendung kommt. Hierbei dürfen persönliche Daten nur zweckgebunden genutzt werden. Testing gehört nicht dazu und bedeutet, dass ein Testing mit produktiven Kundendaten nicht zulässig ist (ausser es wird das Einverständnis der betroffenen Person eingeholt). Das Nichteinhalten kann teuer werden. Bis zu 20 Mio EUR plus ggfs. Schadensersatzforderungen.

Neben diesen Punkten bringen gute Testdaten nichts, wenn diese nicht im richtigen Umfang, auf der richtigen Umgebung zum richtigen Zeitpunkt in der richtigen Qualität bereitgestellt werden.

Risiken

Sofern die oben aufgeführten Punkte beachtet werden/wurden, steht einem erfolgreichen Testing nichts im Wege. Ist dies nicht der Fall, können Risiken entstehen, die gemanaged werden müssen. Die Risiken lassen sich klassisch in folgende Kategorien einteilen:

• Produktrisiko
• Projektrisiko
• Unternehmensrisiko

Ein Produktrisiko besteht z.B. wenn die Testdaten nicht den fachlichen Anforderungen entsprechen und/oder nicht alle geschäftskritischen Kombinationen abdecken. In diesem Fall könnten unentdeckte Fehler in der Produktion landen.

Ein Projektrisiko besteht z.B. dann, wenn die Testdaten nicht rechtzeitig definiert oder bereitgestellt werden. Es kommt somit zu Verzögerungen im Projekt.

Ein Unternehmens-Risiko besteht insbesondere in der Nichteinhaltung von gesetzlichen und branchenspezifischen Vorgaben. Wie oben erwähnt kann dies teuer werden und zu einem hohen Risiko für das Unternehmen werden.

Fazit

Da wir nun die Probleme, Herausforderungen und Risiken eines fehlenden Testdatenmanagement kennen, wird sich mein nächster Blog mit der Erarbeitung einer geeigneten Testdatenstrategie und Testdatenkonzept befassen. So stayed tuned.

27. März 2020, Frederic Hesse

Unser Quality und Testing Angebot

Wir betrachten das Thema Softwarequalität gesamtheitlich und unterstützen mithilfe unserer langjährigen Erfahrung und kontinuierlichen Weiterbildung dort, wo wir den grössten Mehrwert für Sie und Ihr Vorhaben leisten. Dabei sprengen wir bewusst die Fesseln klassischer Projektrollen und konzentrieren uns auf Fähigkeiten, die übergreifend Ihrer Softwarequalität zugute kommen.
> Mehr erfahren