Ist ein Test mit den Daten von gestern noch etwas wert?

Reiseerlebnis: Motocoupé, SAP und der „Wind von gestern“.

„Folgen Sie der Route“. Der Navigationsassistent besteht darauf.

„Wenn ich könnte, würde ich“, ist eine vernünftige Antwort, mit Blick auf die Verkehrssituation. Und in diesem Moment quetscht sich ein kleines Auto in eine nahezu nicht-existierende Parklücke. Fast wie ein sanfter Lufthauch, der dir zuflüstert „Sehe dich an der Ziellinie“ und winkt mit imaginärer Hand.

In den späten 50er-Jahren wurde ein kleines Blasen-förmiges Auto mit dem Namen „Isetta“ (siehe Abbildung 1) zum Symbol für das Wirtschaftswunder. Es reservierte sich damit einen ikonischen Platz in der Welt der Automobilgeschichte.

Testdaten in SAP-Testautomatisierung-Projekten ähneln diesem Auto sehr. In SAP ist das richtige Testdatenmanagement kein Luxus, sondern eher eine Notwendigkeit und manchmal auch die einzige Option, um von A nach B zu kommen. Sowohl das SAP-Testdatenmanagement als auch die Isetta können im Unterhalt kostenintensiv werden. Im Worst-Case-Szenario kann ein falsch gehandhabtes SAP-Testdatenmanagement ein ganzes Projekt zerplatzen lassen, wie eine Blase.

Heutzutage ist für viele Firmen eine SAP-Lösung das Rückgrat aller Geschäftsprozesse. Diese Abhängigkeit bringt wichtige Fragen mit sich: Wie ist das Set-up des Testdatenmanagements am effizientesten zu gestalten? Wie definiert sich Prozesseffizienz in diesem Fall? Wie relevant können Tests sein, wenn diese mit alten Daten durchgeführt werden?

Los geht es! Gehen wir den Weg gemeinsam und finden wir heraus, welche Antworten und Lösung uns erwarten:

• Starten wir mit dem Navigationshandbuch und blicken allgemein auf den Testdatenmanagement-Prozess.
  
• Entlang einer Roadmap gehen wir die wiederkehrenden Herausforderungen des Kontinuierlichen Testdatenmanagements an.
  
• Wie bei der Isetta das Lenkrad so steuern die SAP-Testdatentypen die Ansätze zur Testdatenbereitstellung.

Mit Erreichen der Zielgerade werden alle Ergebnisse zusammengefasst.

Testdatenmanagement: Navigationshandbuch

Jeder Tester hat in seiner Karriere zumindest einmal davon gehört: „Es ist nur ein Fehler, wenn er auf meinem System reproduzierbar ist“. Und dies wurde höchstwahrscheinlich durch eine fehlende Datenkombination auf „diesem System“ verursacht.

Die richtigen Testdaten sollen einheitlich, realistisch, aktuell und relevant für den Prozess, sowie bei allen verschiedenen Systemen integriert sein, wenn diese benötigt werden. Um eine hohe Qualität der Testdaten zu erreichen, ist ein durchdachter Testdatenmanagement-Prozess erforderlich.

Klassisch wird der Prozess abgedeckt von drei grundlegenden Stufen (siehe Abbildung 2). Die Vorbereitungsphase besteht aus folgenden Themen:

• Testdatenkategorisierung: Es ist wichtig, dass alle Parteien ein einheitliches Verständnis der Begrifflichkeiten zum Thema „Testdaten“ und deren Kategorisierung erlangen. Erschwert wird dies, wenn zusätzlich die Testautomatisierung involviert wird.
• Identifizierung von Testdatenanforderungen: In der Welt von COTS-Solutions1sind viele Testfälle so formuliert, dass unternehmensinterne Erfahrungen benötigt werden, um diese zu verstehen und alle wichtigen Datenmerkmale zu erfassen. Es ist wichtig, alle Erkenntnisse zu sammeln und einen Katalog der Testdatenanforderungen zu erstellen. Es kann initial in einer einfachen Excel-Liste geführt und später in ein Tool überführt werden.
• Die Abstimmung mit dem Datenmigrationsteam und dem Testumgebungsmanagement: Die Testaktivitäten werden mit der Datenmigration zeitlich abgestimmt und es wird versucht, so viel transformierte/ migrierte Daten wie möglich zu verwenden. Es ist entscheidend, die einzelnen System-Schnittstellen und deren Datenabhängigkeiten zu verstehen, um zu sehen, wie die Daten die jeweiligen Testszenarien verschachtelt werden.

Die Ausführungsphase nimmt so viel Zeit in Anspruch wie die Vorbereitungsphase und beinhaltet:

• Testdatenmaskierung umfasst die Definitionen von Methoden und Regeln für Datenmaskierung, die Klassifizierung der zu maskierenden Datentypen und die Maskierung selbst.
• Die Identifizierung und Bereitstellung von Testdaten.
• Während der Testdurchführung werden die vorbereiteten Daten genutzt und sollten nach Einsatz als „verbraucht“ markiert und gegebenenfalls erneuert werden.
• Die Aktualisierung von Testdaten ist der Schlüssel für ein stabiles, automatisiertes Testing.

Die Abschluss-Phase:

• dient der Testdatenarchivierung, die für die Compliance-relevante Tests (für Audits) wichtig ist.
• führt zu Lessons Learnt und unterstützt damit die Verbesserung des Testdatenmanagement-Prozesses. Einer der interessanten KPIs könnte hier die Anzahl der falsch-positiven Fehler sein, die durch Datenprobleme verursacht werden.

Kontinuierliches Testdatenmanagement und -Bereitstellung: „Challenge Roadmap“

Grundsätzlich kann die Liste von Herausforderungen hier endlos sein, wie ein Highway in der Wüste. Ein erheblicher Teil bezieht sich auf die Qualität oder auf die Markteinführungszeit einer Lösung:

• Relevanten Testdaten werden vermisst.
• Fehlende Verknüpfungen eines zu überprüfenden Prozesses mit klar definierten Datenattributen, die den gesamten Test in die Irre führen können.
• Der Datenschutz wird vergessen. Zum Beispiel gab es bereits Fälle in der Vergangenheit, in denen Rechnungen aus dem Testsystem versehentlich an echte Kunden verschickt wurden.
• Die Testvorbereitung nimmt eine lange Zeit und einiges an Aufwand in Anspruch.

SAP-Testdaten Lenkrad & Testdaten Cockpit

Die SAP-Testdaten werden im SAP-Testdaten Lenkrad und im SAP-Testdaten Cockpit veranschaulicht.

SAP-Testdaten Lenkrad: Anforderungsszenarien für Testdaten

Zur Veranschaulichung der Datenkomplexität in SAP betrachten wir mögliche Anforderungsszenarien für Testdaten. Diese Szenarios können als Lenkrad dargestellt werden, das die Ansätze zur Datenbereitstellung steuert (siehe Abbildung 3).

Im Kern der Betrachtung stehen die Stammdaten (engl. Master Data). Klassisch sind diese Materialien-, Kunden-, Lieferanten-Stammdaten sowie für die Systemkonfiguration nötige, zugehörige Daten wie Verkaufs- oder Einkaufsorganisation. In diesem Fall wird unterschieden zwischen:

• „Exhaustible Master Data“ sind Daten, die nach der Testdurchführung „verbraucht“ sind.
• „Non-exhaustible Master Data“ können mehrfach benutzt werden für die Szenarios wie Lieferanten oder Preislisten in den Kundenstammdaten usw.

Die zweite Ebene sind die Transaktionsdaten, die auf den Stammdaten basieren (Verträge, Kunden- oder Einkaufsaufträge usw.). Diese Daten sind immer als „Exhaustible“ klassifiziert und passen meist zu drei Szenarien:

• Daten können durch die Ausführung von den Prozessschritten in einem End-to-End(E2E)-Prozess generiert werden.
• Daten können gemockt werden, um bestimmte Stand-alone-Tests aus einem E2E-Prozess zu ermöglichen.
• Transaktionsdaten, die aus der Integration mit Nicht-SAP oder Drittsystemen stammen.

Die letzte Ebene sind die Historischen Daten. Im weiteren Sinne handelt es sich dabei auch um Transaktionsdaten, die jedoch über einen bestimmten Zeitraum hinweg gesammelt werden. Zum Beispiel erfordern FnR-Algorithmen3 historische Verbrauchsdaten. Eine Möglichkeit zur Erstellung der Verbrauchsdaten wäre, mehrere E2E-Prozesse im Test so ablaufen zu lassen, dass sie in der Lage wären, Daten zu generieren, welche historischen Daten ähneln könnten. Die zweite Möglichkeit ist es, Daten aus dem migrierten Datensatz oder einer Teilmenge zu nehmen.

SAP-Testdaten Cockpit: Tipps, Tricks und Vorgehensweisen für die Testautomatisierung

Grundsätzlich gibt es drei Ansätze für das Management der Testdaten:

• Daten neu zu erstellen (sowohl Transaktionsdaten als auch Stammdaten),
• Daten aus dem bestehenden Datenbestand zu identifizieren und zu verwenden,
• „verbrauchte“ Daten wieder in einen nutzbaren Zustand zu bringen.

In der Testautomatisierung ist eine Erstellung von Testdaten relativ einfach, falls die benötigten Testattribute bekannt sind. Eine Möglichkeit ist, zusätzliche automatisierte Tests zu schreiben, um Datenvoraussetzungen durch manuelle Buchungen oder „Idocs“ zu erzeugen. Der Ansatz eignet sich auch sehr gut für die E2E-Automatisierung, wenn Transaktionsdaten während der Testausführung selbst erzeugt werden.

Eine gehobenere Methode besteht darin, die Tests logisch zu gruppieren, sodass diese dazu beitragen, Testdaten füreinander zu erstellen. So sollten beispielsweise Beschaffungsszenarien vor verkaufsbezogenen Tests durchgeführt werden.

Die Identifizierung und Bereitstellung von Daten aus dem vorhandenen Datenbestand ist schwieriger. Hier bestehen zwei Möglichkeiten:

• Die Vorbereitung zusätzlicher automatisierter Skripte zur Datenidentifikation und deren Ausführung vor dem automatisierten Haupttestszenario. Dies erfordert ein detailliertes Verständnis der für den Test wichtigen Datenattribute und sollte in die Testdurchführung integriert werden.
• Die manuelle Aufbereitung und Aktualisierung des Testdatensatzes (Testdatencontainer, Testdatenbank usw.).

Der dritte und letzte Ansatz bezieht sich wieder auf die funktionalen Möglichkeiten in einem zu testenden System. Automatisierte Tests können so sequenziert oder vorbereitet werden, dass ein zu testender Prozess entweder logisch beendet oder vollständig rückgängig gemacht wird, was die Testdaten wieder in einen nutzbaren Zustand bringt. Zum Beispiel, die für einen Vertrag durchgeführte Änderungen können im System eingereicht und genehmigt werden. Dann wird der Vertrag wieder änderbar und kann für denselben Test wiederverwendet werden.

Zusammenfassung: Überquerung der Zielgeraden

Auf unserem Weg durch das SAP-Testdaten-Gebiet haben wir gezeigt, dass:

• aktuelle und produktionsnahe Testdaten sowie das Verständnis der Datenstruktur und der Anforderungen an die Testdaten der Schlüssel für einen zuverlässigen Test sind.
• ein effizienter Prozess für das Testdatenmanagement aus drei klassischen Phasen besteht, verschiedene Beteiligte umfasst und auf die Strategie und den Zeitplan für die Datenmigration abgestimmt sein sollte.
• Testdatenmanagement-Ansätze in der SAP-Testautomatisierung durch die, für die Testszenarien erforderlichen, Datentypen bestimmt werden können.