Was erwarten die Unternehmen von Testautomatisierung? Neben einer Kosteneinsparung und schnelleren Reaktionszeiten (Time to Market) haben die meisten das Ziel, die Tests auf verschiedenen Umgebungen, mit verschiedenen Daten bzw. Datenausprägungen in regelmässigen Abständen durchzuführen.
Doch denken die Unternehmen dabei an das Testdatenmanagement? Mit welchen Daten soll die Testautomatisierung durchgeführt werden? Wie können Rückschlüsse von den Input-Daten auf die erwarteten Output-Daten gemacht werden? Auf diese und ähnliche Fragen möchte ich in diesem Blog-Beitrag eingehen. Zuvor ist allerdings noch etwas Theorie über die zwei Themen Testautomatisierung und Testdatenmanagement notwendig….
Testautomatisierung ist die Ausführung von Tests ohne menschliche Interaktion. Prinzipiell sind für die Ausführung der automatisierten Tests sowohl Input-Daten als auch die zu erwarteten Output-Daten notwendig. Basierend auf den Input-Daten überprüft die Testautomatisierung nun das entstandene Ergebnis mit den zu erwarteten Daten.
Das Testdatenmanagement betrifft die Planung, Steuerung und Durchführung aller Aktivitäten im Zusammenhang mit Testdaten. Die gewonnen und generierten Daten eines Unternehmen liegen in unterschiedlichster Form vor. Man spricht u.a. von Stammdaten, Transaktionsdaten, Bewegungsdaten, Metadaten, hierarchische Daten... In diesem Beitrag will ich lediglich auf Stamm- und Transaktionsdaten eingehen. Die anderen Datenkategorien werden nicht weiter untersucht.
Grundlegend werden 3 verschiedene Testdatentypen unterschieden:
- Produktive Daten: Produktive Daten entsprechen realen Daten aus der Produktionsumgebung (Echtdaten).
- Anonymisierte Daten bzw. Pseudonyme Daten: Unter anonymisierten Testdaten versteht man die derartige starke Veränderung der Echtdaten, so dass unter keinen Umständen ein Rückschluss auf die betroffene Person möglich ist. Bei pseudonymen Testdaten werden einzelne Identifikationsmerkmale mit einem Pseudonym beziehungsweise Decknamen ersetzt, z.B. Testobjekt „Benutzer“: Markus Frei wird zu Otto Müller
- Synthetische Daten: Synthetische Testdaten sind fiktive selbstgenerierte Daten.
In den Artikeln "Praxisbeispiel: Testdaten generieren vereinfacht das (manuelle) Testen" und "Praxisbeispiel Wie beherrscht man Testdaten für Testautomation erfolgreich?" sind bereits einige Beispiele über die Generierung und den Einsatz von Testdaten aufgeführt. Insbesondere im Artikel „Praxisbeispiel: Testdaten generieren vereinfacht das (manuelle) Testen” werden die Unterschiede zwischen Stamm- und Bewegungsdaten aufgezeigt.
In diesen Beispielen war es jeweils möglich, die Testdaten zu erstellen bzw. nach einem Testlauf zurückzusetzen. Dieses Vorgehen ist oftmals nicht möglich bzw. nur mit sehr grossen Bemühungen. Aus diesem Grund möchte noch ein weiteres Praxisbeispiel aufführen.
Ausgangslage
Der Auftrag eines grossen Detailhändlers lautete, den Bestellprozess mehrerer Onlineshops mit verschiedenen Zahlungsmöglichkeiten (Vorkasse, Kreditkarte,...) End-to-End zu automatisieren, d.h. vom Kundenauftrag, Bestellung beim Lieferanten über Auslieferung bis hin zur Fakturierung und das alles über die GUI.
Vorgehen
Wir haben sehr schnell festgestellt, dass etliche Systeme im gesamten Prozess Daten liefern bzw. mit Daten beliefert werden. Angefangen mit den verschiedenen Onlineshops, Zahlungsinstitute, SAP Systeme und Lieferantensysteme. Durch die komplexe Systemlandschaft war ein einfaches und schnelles Zurücksetzen von Daten nicht möglich.
Das Verwenden von bereits existierenden Kundenbestellungen (produktive Daten) für die Testautomatisierung haben wir gleich zu Beginn ausgeschlossen. Hierbei kann nie gewährleistet werden, dass eine Bestellung mit den gewünschten Ausprägungen, z.B. Zahlung mit Kreditkarte eines Streckenartikels, im System vorhanden ist. Zudem handelt es sich bei einem Kundenauftrag um Transaktionsdaten. Diese werden somit durch die Testautomatisierung „verbraucht“ und stehen nicht mehr in der gewünschten Form zur Verfügung (Die Tests selbst zerstören sich die Testdaten - siehe Blog: Praxisbeispiel: Testdaten generieren vereinfacht das (manuelle) Testen).
Die zwei Feststellungen
- Testdaten können nicht zurückgesetzt werden
- Produktive Testdaten können nicht verwendet werden
hatten einen entscheidenden Einfluss auf den Aufbau, das Vorgehen und die Implementierung der Testautomatisierung.
Somit war klar, dass wir unsere Kundenaufträge (Transaktionsdaten) zu Beginn eines automatisierten Testlaufs immer zuerst mit den gewünschten Ausprägungen anlegen mussten (Erstellung synthetischer Testdaten). Beispielsweise der Kauf eines Cross-Trainers, Fitnesshandschuhe inkl. Lieferung und Aufbau oder der Kauf eines Fernsehers und eines Blueray Players mit Abholung in einer Filiale. Anschliessend wurde der Auftrag im SAP-System weiterverarbeitet.
Implementierung Testautomatisierung
Ausschlaggebend für eine funktionierende Testautomatisierung der End-to-End Bestellprozesse war somit das Anlegen von Kundenaufträgen mit verschiedenen Ausprägungen. Meine Erfahrung hat gezeigt, dass das Anlegen eines Kundenauftrags über das GUI der Onlineshops sehr instabil ist. Daher haben wir bei der Implementierung einen anderen Weg eingeschlagen. Wir haben die Kundenaufträge über einen Web Service direkt im SAP System angelegt. Die dazugehörigen Daten eines Auftrags, wie. z.B. Auftragsnummer, Liefer- und Rechnungsadresse, Zahlungsart sowie die gewünschten Artikel wurden in einem definierten Excel Template gepflegt und jeweils mit einer eindeutigen ID versehen. Die Testautomatisierung hat nun alle Daten einer entsprechenden ID ausgelesen und in die geforderten XML-Formate transformiert. Die entstandenen XML Dateien wurden nun an den Web Service gesendet. Der weitere Teil der Testautomatisierung, welche sich im SAP Backend abspielte, konnte über das GUI durchgeführt werden.
Dieser Lösungsansatz hat das Anlegen eines Auftrags über den Onlineshop simuliert und hatte den Vorteil, dass es von den verschiedenen Onlineshops unabhängig war, die des Öfteren aufgrund von Weiterentwicklungen nicht zur Verfügung standen (siehe untenstehende Grafik)
Für die Implementierung war wichtig zu wissen, aus welcher Datenquelle der angelegte SAP Kundenauftrag stammt. Aus diesem Grund haben wir eine eigene Nummerrange für die Testautomatisierung definiert.
Implementierung Testdatenmanagement
Die Pflege der Excel Datei mit den dazugehörigen Testdaten, d.h. die Ausprägungen der verschiedenen Kundenaufträge mit den dazugehörigen Stammdaten der Artikel lag in der Verantwortung der Fachtester und nicht beim Testautomatisierer. Dieser Umstand hat zu Beginn etwas Überzeugungsarbeit bei den Fachtestern verlangt. Die Vorteile der enormen Zeitersparnis und der grösseren Testabdeckung haben schliesslich alle überzeugt.
Dieses komplexe Beispiel eines Detailhändlers zeigt deutlich auf, wie die vorgegebene Systemlandschaft als auch getroffene Entscheidungen im Testvorgehen einen gravierenden Einfluss auf die verwendeten Testdaten und somit auch auf die Implementierung der Testautomatisierung haben.
Damit ein Unternehmen nun erfolgreich den Testdatenprozess als auch die Testautomatisierung beherrschen kann, ist ein klar definiertes Vorgehen notwendig.
Ein mögliches Vorgehen, welches wir auch in dem aufgeführten Beispiel angewendet wurde, sieht wie folgt aus:
Fazit
Schlussendlich kann gesagt werden, dass es kein generelles Konzept bzw. Lösung für das Testdatenmanagement und die Testautomatisierung gibt. Jedes Projekt hat andere Rahmenbedingungen, die einen Einfluss auf das Testdatenmanagement und somit auf die Testautomatisierung haben. Es kann lediglich ein einheitliches Vorgehen definiert werden. Wird das Vorgehen eingehalten, dann steht einem guten Testdatenmanagement und somit einer funktionierenden Testautomatisierung nichts mehr im Wege.