Herzlich willkommen zum dritten und letzten Teil meines Blogs «Künstliche Testdaten sind super!»
Im ersten Teil sind wir in die Vor- und Nachteile, Voraussetzungen und Testautomation mit künstlichen Testdaten, Echtheit und Diversifikation eingegangen. Im zweiten Teil wurden praktische Beispiele beschrieben, und wie man wo künstliche Testdaten ideal einsetzen kann. Dieser dritte und letzte Teil behandelt weiterführende wichtige Punkte oder Vorschläge, die bei künstlichen Testdaten zu beachten sind: Tools, Reverse Engineering, Aufwand und Ertrag, Unterhalt und Workflow.
Wieso ein Tool?
Es gibt kein Programm, das Testdaten ladet und das man fixfertig kaufen kann. Es ist eine Kombination aus bestehenden Tools und Eigenentwicklungen. Für einen simplen Funktionstest, der nur wenige einfache Testdaten benötigt, reicht es die Testdaten direkt in die Datenbank einzufügen.
Stellt euch jetzt aber vor, ihr steht vor einem umfangreichen Systemtest einer Applikation, die hunderte Funktionen und Prozesse beinhaltet, entsprechend gross ist die benötigte Testdatenmenge. Die benötigten Testdaten direkt in die Datenbank einfügen? Nein Danke! Der dazu benötigte Code wäre riesig. Dieser wäre kaum noch zu unterhalten. Der Code würde umso unübersichtlicher und komplexer, sobald dynamische Variablen eingesetzt werden. Ein klassischer Fall dafür sind das Datum und davon abhängige Daten, die sich jeden Tag ändern. Somit öffnet sich nur die Büchse der Pandora.
Anforderungen an das Tool
Was sollte so ein Tool können? Dazu sollte man sich vor der Anschaffung Gedanken machen. Es folgen ein paar Überlegungen, die euch dabei helfen.
Bedienbarkeit
Ein Programm, das die künstlichen Testdaten «automatisch» ladet, ist meiner Meinung nach Pflicht. Meine persönliche Präferenz ist eine Kombination aus einem «Verwaltungsprogramm» wie Excel und einem eigentlichen «Ladeprogramm». Ein Verwaltungsprogramm wie Excel bietet einfache Bedienbarkeit und jeder kann es anwenden. Weiterhin visualisiert Excel die Daten auf eine bekannte Weise. Das unterstützt bei der Erstellung und Verwaltung der Daten. Das Ladeprogramm extrahiert die Daten das dem «Verwaltungsprogramm», konvertiert sie bei Bedarf in ein weiteres Format um (z. B. CSV oder XML), und sorgt dafür, dass diese in die Datenbank/Applikation geschrieben werden. Das Ladeprogramm ist derjenige Teil, der unternehmensspezifisch entwickelt werden muss.
Anders formuliert: Braucht der Nutzer Programmiersprachenkenntnisse, damit er die Testdaten verwalten kann, ist meiner Meinung ein wichtiges Ziel verfehlt.
Flexibilität
Ob ein Standard-Testdatensatz mit 1 User mit 1'000 Emails oder einen extremen Testdatensatz (50'000 Anwender mit jeweils Zehntausenden von Emails), der Tool-User muss dies selbständig mit wenig Aufwand erstellen können. Excel und ähnliche Programme bieten diesen Vorteil von Haus aus. Verwaltung der Testdaten in Excel oder in einer ähnlichen «visuellen» Applikation ist einfach zu verstehen und jeder kann die Daten bearbeiten. Excel beispielsweise bietet mit seinen Formeln viele elegante Möglichkeiten zur Multiplizierung und Skalierung von Testdaten, Nummerierung, Berechnungen von beispielsweise IBAN-Kontonummern, oder Datierung von Buchungen und vieles mehr.
Erweiterbarkeit
Wenn durch neue Funktionen neue Datenwerte benötigt werden, braucht die Anwendung im Idealfall keine oder nur eine kleine Anpassung. Der User ergänzt zum Beispiel das Excel mit einer weiteren Spalte. Die Applikation lädt die Testdaten im Idealfall ohne, dass ein Entwickler Anpassungen im Code des Tools vornehmen muss.
Kompatibilität & Validierung
Ein anderer wichtiger Punkt ist, dass das Laden der Testdaten validiert wird vor dem Ladeprozess. Es soll verhindert werden, dass invalide Daten in der Datenbank landen. Dazu gehören ein fachliches Review der Testdaten und auch eine technische Validierung, das beispielsweise durch Metamodelle gewährleistet werden kann.
Abhängigkeiten zu umgebenden Systemen
Hier bestehen die grössten Risiken und Aufwände. Wenn Testdaten von umgebenden Systemen in-house oder extern benötigt werden, gibt es viele Hürden zu nehmen. Oft hat man zum Beispiel keine Administratorenrechte oder überhaupt einen Zugang, ausser über die Schnittstellen. Ideal wäre es, wenn das Ladeprogramm alle benötigten Systeme mit Daten bespielen könnte.
Ihr erkennt schon, hier lässt sich mit wenigen externen Systemen die Büchse der Pandora öffnen. Überlegt euch, ob externe Datenbanken mit einem Mock (Simulator) «gefälscht» werden können, um Probleme mit externen Systemen zu umgehen.
Reverse Engineering
Ich kann mir vorstellen, dass schon einige diese Aussage gehört haben: «Künstliche Testdaten sind schlecht. Sie sind nicht wie echte Daten.» Trotzdem sollte das Arbeiten mit echten Testdaten entschieden abgelehnt werden! (siehe erster Teil des Blogs)
Wie kann man «relativ einfach» echt aussehende künstliche Testdaten kreieren? Durch Reverse Engineering, sprich durch Nachahmen und Nachbauen (nicht mit Kopieren zu verwechseln) von produktiven Daten. Voraussetzung dafür ist, dass es schon eine grosse und vielfältige Menge an produktiven Daten gibt. Diese Vorgehensweise ermöglicht eine hervorragende Diversifikation. Die so erhaltenen künstlichen Testdaten können dann im «Verwaltungsprogramm» (Excel oder ähnlich) erweitert und angepasst werden. Die Selektion aus den echten Datensätzen muss mit Sorgfalt geschehen und den Anforderungen gegenübergestellt werden. Eine relativ kleine Anzahl an Test-Accounts wird das Gros der wichtigsten Testfälle abdecken können. Versucht dabei folgende Fragen zu beantworten:
- Welche Äquivalenzgruppen, Anforderungen und Testfälle decken die Accounts aus der Produktion ab?
- Brauche ich für die Tests einen eigenständigen (neuen) Testdatensatz oder kann es durch eine Erweiterung bestehender Testdaten abgedeckt werden?
- Welche Testdatensätze werden von einer Gruppe von Tests benötigt?
- Muss der komplette Datensatz oder nur ein Teil davon berücksichtigt werden?
Ganz nach Vilfredo Pareto, versucht nicht von Anfang an alle Situationen abzudecken. Mit 20% Aufwand werden 80% der Testfälle abgedeckt sein. Testdaten werden sich anhand der Anforderungen sowieso verändern, sie müssen leben. Ergänzt fortlaufend die künstlichen Testdaten. Wenn produktive Daten kopiert werden, denkt an die Datenschutzgesetze und eine eventuell erforderliche Anonymisierung!
Aufwand und Ertrag?
Der Aufwand kann sehr schnell sehr gross werden. Dazu gibt es keine einfache und allgemein gültige Herangehensweise. Schön wäre es! Jedes Projekt, jede Situation muss einzeln analysiert werden.
Mir scheint, dass viele Firmen sich davor scheuen, weil sie nur den Aufwand sehen. Die Ansprüche an die Qualitätssicherung steigen jedoch rasant an. Tägliche automatisierte Test Runs mit Hunderten oder Tausenden von Tests. Wachsende Regression Tests. Soll die Qualität der Software regelmässig, abdeckend, schnell und stabil getestet werden, wird eine genaue Analyse aufzeigen, dass man mit künstlichen Testdaten Kosten sparen kann. Kosten zum Beispiel durch False Positives wegen «fehlerhaften» Testdaten (siehe erster Teil des Blogs). Eine nähere Analyse lohnt sich also.
Ein weiterer Aspekt, den es bei dieser Analyse zu beachten gilt, ist der Zeithorizont. Für kurzfristige Projekte besteht die Gefahr, noch in der Testdatenanalyse zu stecken, während die Applikation schon lange in Produktion ist! Für mittel- und langfristige Projekte wird die Qualitätssicherung merklich verbessert, hat man die Initialphase hinter sich. Die Testergebnisse werden stabile und aussagekräftige Resultate liefern.
Der Aufwand steigt je öfter die Anforderungen sich ändern. Werden die Release Zyklen schneller, verändern sich auch die Anforderungen an die Testdaten schneller. Ist die Bedienbarkeit des Verwaltungstools einfach, kann die Erstellung und Verwaltung der künstlichen Testdaten das Tempo der Releases mithalten. Das führt dazu, dass Defects aus Regressionen zuverlässiger aufgedeckt werden und die Anzahl falscher Testbefunde minimiert werden können.
Eine saubere Versionierung der Testdaten ist sehr hilfreich bei der Verwaltung und der Testausführung. Die Versionen können mit Anforderungen und Testfälle verlinkt und somit einfach zurückverfolgt werden. Wie so oft, wenn es um Qualität geht, ist der Ertrag schwierig zu ermitteln. Ein wichtiger Ansatzpunkt ist dabei die Anzahl der Tests, die über eine gewisse Laufzeit stabil durchlaufen und verlässliche Testresultate liefern. Im Idealfall alles Grün!
Unterhalt der Testdaten
Der Unterhalt ist eine nicht zu unterschätzende laufende Aufgabe, die miteinkalkuliert werden muss. Der Unterhalt der Testdaten sollte daher möglichst einfach sein, so dass jeder Tester, Requirements Engineer und andere Beteiligte ohne Entwicklerknowhow die Testdaten lesen, verstehen und anpassen kann.
Deshalb bevorzuge ich persönlich die «Excel»-Lösung. Die Daten sind visualisiert, fast alle können damit umgehen, Formeln ermöglichen dynamische und flexible Anpassungen und Datensätze können durch Copy-Paste schnell und einfach multipliziert werden.
Der Unterhalt der Testdaten erfordert auch eine korrekte und durchgängige Verknüpfung zu den Anforderungen. Andernfalls wird die Wartung schwierig oder im schlimmsten Fall unmöglich. Das gilt für Anforderungen der getesteten Applikation, der Datenbank und andere Teile im Hintergrund wie aber auch für das Ladeprogramm selbst.
Ebenso sollte eine Versionierung der Testdaten stattfinden. Das hilft zum Beispiel beim Testen neuer Dateninhalte und -strukturen. Die neuen Testdaten werden geladen und getestet. Ist alles korrekt, können die geänderten Testdaten in eine neue Version übergeben werden (Commit). Bei Problemen mit der neuen Testdatenversion kann der Tester weiterhin mit der stabilen alten Version arbeiten.
Workflow
Stark vereinfacht: Egal welches Entwicklungsmodell eingesetzt wird (Agile, V-Modell, Wasserfall), die erste Analyse muss schon ganz früh zusammen mit den Entwicklern und Business Analysten starten. Die Testdaten müssen von Anfang an ein Gesprächsthema sein. Braucht es «nur» eine Anpassung oder müssen neue Testdaten erstellt werden? Die Business Analysten sorgen dafür, dass die Testdaten fachlich alles abdecken. Die Entwickler helfen bei Bedarf beim Aufbau der Testdaten. Der Tester testet die Neuerungen und commited die Änderungen.
Abgesehen von kurzfristigen Projekten, die nur ein paar Wochen oder Monate dauern, sollten die Testdaten spätestens dann bereit sein, wenn die Test Cases ausgeführt werden sollen. Keine Testdaten, keine Testausführung!
Risiken
- Unterhalt
Der Unterhalt wächst mit der Testdatenmenge, Systemgrösse und -komplexität und darf nicht unterschätzt werden. Hier hilft nur diszipliniertes Arbeiten und Rückmelden der benötigten Zeit.
- Komplexität & Systemarchitektur
Je komplexer das System, desto komplexer die Testdaten (üblicherweise). In dieser Situation kann es sein, dass abdeckende Testdaten nie möglich sein werden. Aber eventuell kann man mit den einfachsten oder am häufigsten benötigten Testdaten anfangen und das Testing verbessern.
- Testdatenmenge
Die Testdatenmenge kann über die Zeit enorm anwachsen. Es bedarf einer gewissen Kontrolle um dem entgegen zu wirken. Nicht jeder Testfall braucht seine individuellen Testdatensatz, denn oft kann ein schon bestehendes Template benutzt werden.
- Akzeptanz
Fehlt die Akzeptanz von verschiedenen Abteilungen, wird es schwierig künstliche Testdaten einzuführen. Dazu braucht es klar aufzeigbare Vorteile der künstlichen Testdaten, einfach zu bedienende Tools und die Testdaten sollten echten Daten nachgeahmt sein.
- Datenschutz
Ein wichtiger rechtlicher Aspekt ist der Datenschutz. Eine Anonymisierung ist Pflicht, wenn produktive Daten zum Einsatz kommen. Eine 100%ige Anonymisierung ist ein aufwändiger Prozess und muss bei Bedarf eingeplant werden.
Fazit «Künstliche Testdaten sind super!»
Künstliche Testdaten sind meiner Meinung nach super! Zweifellos. Lohnt sich der Einsatz in Ihrem Projekt? Gut möglich. Scheuen Sie nicht den Initialaufwand, machen Sie eine Machbarkeitsanalyse. Künstliche Testdaten benutzt durch automatisierte Testfälle? Ergibt nach einem Klick innert kürzester Zeit zuverlässige Testresultate, ergo glückliche Kunden.
Kämpft Ihr noch mit Testdaten, oder ladet Ihr sie schon! SwissQ steht Ihnen zur Seite bei der Analyse und Erstellung künstlicher Testdaten. Wir helfen Ihnen gerne mit unserer Expertise weiter.
