End-to-End-Tests sollen einen fachlichen Prozess möglichst realistisch von Anfang bis Ende prüfen. In modernen Anwendungen wird dafür häufig viel über Testautomatisierung, Playwright, Cucumber oder wiederverwendbare Testszenarien gesprochen. Diese Werkzeuge sind wichtig. Aber sie können nur so gut testen wie die Daten, mit denen sie arbeiten.
Gerade bei komplexen Fachanwendungen wie einem Steuerdeklarationssystem reicht es nicht, irgendeinen Datensatz bereitzustellen und anschliessend einen automatisierten Test darüber laufen zu lassen. Ein Testdatensatz muss fachlich geeignet, technisch konsistent, reproduzierbar, sicher und für das konkrete Szenario nachvollziehbar sein.
1. E2E-Testing ist mehr als ein Klickpfad
Ein End-to-End-Test prüft nicht nur, ob ein Benutzer von einer Maske zur nächsten navigieren kann. Er soll möglichst den vollständigen fachlichen Ablauf betrachten: Eingaben, Validierungen, Berechnungen, Datenübernahmen, Speicherung, Folgeschritte und das erwartete Ergebnis.
Damit ein solcher Test belastbar ist, müssen die zugrunde liegenden Daten zum Szenario passen. Ein fachlicher Spezialfall benötigt andere Ausgangsdaten als ein Standardfall. Ein Berechnungstest braucht andere Daten als ein reiner Navigationstest. Ein Test für Fehlermeldungen wiederum benötigt gezielt unvollständige, widersprüchliche oder grenzwertige Datenkonstellationen.
2. Zuerst verstehen, welche Daten tatsächlich benötigt werden
Bevor Testdaten erzeugt oder aus bestehenden Beständen übernommen werden, muss klar sein, welche fachliche Aussage geprüft werden soll.
- Welche Personen- oder Fallkonstellation ist erforderlich?
- Welche Vorbedingungen müssen bereits im System vorhanden sein?
- Welche Eingabefelder und Datenobjekte sind für das Szenario relevant?
- Welche Werte lösen Berechnungen oder Validierungen aus?
- Welche Abhängigkeiten zwischen verschiedenen Masken oder Datenbereichen bestehen?
- Welche Grenz- und Sonderfälle müssen gezielt abgedeckt werden?
- Welches Ergebnis wird fachlich erwartet?
Diese Fragen verbinden Business Analyse, Datenmodell und Testautomatisierung miteinander.
3. Bestehende Datenbestände analysieren
Häufig existieren bereits grosse Datenbestände, aus denen geeignete Fälle abgeleitet werden können. Dann ist die erste Aufgabe nicht das Erzeugen neuer Testdaten, sondern das gezielte Finden geeigneter Konstellationen.
Hier helfen klassische Werkzeuge der Datenanalyse: SQL-Abfragen, Filterungen, Gruppierungen, Häufigkeitsanalysen, Plausibilitätsprüfungen und Vergleiche zwischen verschiedenen Datenobjekten.
Entscheidend ist jedoch auch hier das fachliche Verständnis. Eine technisch korrekte SQL-Abfrage kann fachlich ungeeignete Fälle liefern, wenn beispielsweise Beziehungen, Kardinalitäten oder Bedeutungen von Attributen falsch interpretiert werden. Deshalb sollte die Suche nach E2E-Testfällen immer auf einem nachvollziehbaren Datenmodell und klar definierten fachlichen Kriterien beruhen.
4. Testdaten gezielt auswählen statt zufällig übernehmen
Gute Testdaten entstehen nicht dadurch, dass ein beliebiger produktiver Fall kopiert wird. Für automatisierte E2E-Tests sollten Daten gezielt nach ihrer Aussagekraft ausgewählt werden.
- Standardfall mit vollständigen und plausiblen Daten
- Minimalfall mit nur den zwingend notwendigen Angaben
- Grenzwertfälle für Berechnungen
- Fälle mit mehreren Einträgen derselben fachlichen Art
- Fälle mit Abhängigkeiten zwischen mehreren Datenbereichen
- Fehlerfälle für Validierungen und Fehlermeldungen
- Vorjahres- oder Übernahmefälle
- Fälle mit bewusst fehlenden oder widersprüchlichen Angaben
5. Daten aufbereiten und reproduzierbar machen
Ein E2E-Test muss wiederholbar sein. Deshalb reicht es nicht, einen geeigneten Datensatz einmalig zu finden. Er muss so aufbereitet werden, dass derselbe Ausgangszustand jederzeit wiederhergestellt werden kann.
Dafür können strukturierte Fixtures, definierte JSON-Daten, vorbereitete Datenbankzustände oder andere reproduzierbare Testdatenquellen verwendet werden. In den bisherigen TM4-Diskussionen war gerade die Wiederverwendbarkeit von Testdaten und Fixtures zusammen mit Playwright/Cucumber ein wichtiges Thema.
Der Vorteil ist erheblich: Entwicklung, Business Analyse und Testing sprechen dann nicht mehr über einen unbestimmten Testfall, sondern über einen konkret definierten Datenzustand, der gemeinsam nachvollzogen werden kann.
6. Personenbezogene und produktive Daten schützen
Sobald echte oder produktionsnahe Daten als Ausgangsbasis dienen, wird der Datenschutz zu einem zentralen Bestandteil der Testdatenaufbereitung. Testumgebungen dürfen nicht einfach zu Kopien produktiver Datenbestände werden.
- Anonymisierung personenbezogener Angaben
- Pseudonymisierung von Identifikatoren
- Ersetzen von Namen, Adressen und Kontaktdaten durch künstliche Werte
- Maskierung besonders schützenswerter Attribute
- Verschlüsselung bei Speicherung und Übertragung
- Begrenzung des Zugriffs auf definierte Testrollen
- Vermeidung unnötiger Kopien vollständiger Produktionsbestände
Wichtig ist dabei, die fachliche Struktur zu erhalten. Eine Anonymisierung darf einen Testfall nicht so verändern, dass beispielsweise Beziehungen zwischen Personen, Objekten oder Zeitständen verloren gehen.
7. Verschlüsselung allein reicht nicht
Verschlüsselung schützt Daten während der Speicherung oder Übertragung. Sie löst aber nicht automatisch das Problem, dass Testende oder automatisierte Prozesse nach der Entschlüsselung wieder auf reale personenbezogene Informationen zugreifen könnten.
Deshalb sollten Verschlüsselung, Anonymisierung oder Pseudonymisierung und Berechtigungskonzepte zusammenspielen. Das Ziel ist nicht nur, Daten technisch zu schützen, sondern gleichzeitig die für den Test notwendige fachliche Aussagekraft zu erhalten.
8. Testdaten und Akzeptanzkriterien gehören zusammen
Ein gutes Akzeptanzkriterium beschreibt nicht nur eine erwartete Funktion, sondern lässt sich mit konkreten Daten prüfen.
Für automatisierte Cucumber-Szenarien bedeutet das beispielsweise: Die Ausgangsdaten, die Benutzeraktion und das erwartete Ergebnis müssen eindeutig miteinander verknüpft sein.
Ein Szenario wie «Dann wird der korrekte Totalbetrag angezeigt» ist ohne definierte Eingabedaten nur begrenzt aussagekräftig. Erst wenn nachvollziehbar ist, welche Werte vorhanden sind, welche Berechnungsregel gilt und welches Ergebnis erwartet wird, entsteht ein belastbarer automatisierter Test.
9. Testdaten als wiederverwendbares Produkt betrachten
In grösseren Projekten lohnt es sich, Testdaten nicht als Nebenprodukt einzelner Tests zu behandeln. Sie sollten wie ein eigenes Qualitätsartefakt gepflegt werden.
- Für welche Testszenarien ist der Datensatz vorgesehen?
- Welche fachlichen Eigenschaften besitzt er?
- Wie wird er erzeugt oder zurückgesetzt?
- Welche Datenobjekte hängen voneinander ab?
- Welche Schutzmassnahmen wurden angewendet?
- Welche erwarteten Ergebnisse sind damit verbunden?
10. Daten für Playwright und Cucumber bereitstellen
Für die eigentliche Automatisierung sollten die Daten so bereitgestellt werden, dass Tests möglichst unabhängig und reproduzierbar ausgeführt werden können.
Dabei kann ein Test vor seiner Ausführung beispielsweise einen definierten Ausgangszustand laden, bestimmte Fixtures verwenden oder über vorbereitete Schnittstellen auf Testdaten zugreifen. Wichtig ist weniger das konkrete technische Format als die klare Trennung zwischen Testlogik und Testdaten.
Wird derselbe Datensatz von mehreren Szenarien benötigt, sollte er nicht mehrfach und unterschiedlich innerhalb einzelner Tests nachgebaut werden. Zentral gepflegte und wiederverwendbare Testdaten reduzieren Inkonsistenzen und vereinfachen spätere Anpassungen.
11. Datenanalyse hilft auch bei fehlgeschlagenen E2E-Tests
Datenanalyse ist nicht nur vor dem Test wichtig. Sie spielt auch bei der Fehleranalyse eine entscheidende Rolle.
- Waren die erwarteten Ausgangsdaten vorhanden?
- Wurde ein Wert bereits durch einen vorherigen Test verändert?
- Ist eine abhängige Entität nicht mehr vorhanden?
- Hat sich eine fachliche Berechnungsregel geändert?
- Wurden Daten aus einer Schnittstelle anders geliefert als erwartet?
- Liegt ein Fehler im Test oder in der Anwendung vor?
12. Die Rolle des Business Analysts
Für mich gehört das Thema Testdaten deshalb unmittelbar zur Business Analyse. Der Business Analyst muss nicht alle Testdaten technisch erzeugen. Er sollte aber verstehen und beschreiben können, welche fachlichen Datenkonstellationen benötigt werden und weshalb.
Besonders wertvoll wird diese Rolle im Zusammenspiel mit Entwicklung und Testing: Der Fachbereich beschreibt die fachliche Erwartung, die Business Analyse strukturiert Regeln und Datenkonstellationen, die Entwicklung schafft die technischen Voraussetzungen und das Testing automatisiert die Szenarien.
13. Vom Einzelfall zu einer systematischen Testdatenstrategie
Mit zunehmender Anzahl automatisierter E2E-Tests wächst auch die Bedeutung einer systematischen Testdatenstrategie.
Statt für jedes neue Szenario spontan Daten zu suchen, entsteht idealerweise ein katalogisierter Bestand repräsentativer Testfälle. Diese können nach fachlichen Merkmalen, Datenbereichen, Sonderfällen und erwarteten Resultaten klassifiziert werden.
Damit wird die Datenanalyse zu einem verbindenden Element zwischen Requirements Engineering, Datenmodellierung, Entwicklung und Qualitätssicherung.
Mein Fazit
Ein E2E-Test ist nur dann wirklich belastbar, wenn auch seine Daten belastbar sind. Testautomatisierung beginnt deshalb nicht mit dem ersten Playwright-Skript und nicht mit dem ersten Cucumber-Szenario.
Sie beginnt mit der Frage: Welche Daten benötige ich, um den fachlichen Sachverhalt eindeutig, reproduzierbar und sicher zu prüfen?
Daten müssen dafür gefunden oder erzeugt, fachlich analysiert, aufbereitet, geschützt, kontrolliert bereitgestellt und mit den erwarteten Ergebnissen verknüpft werden. Erst dann entsteht aus einem automatisierten Ablauf ein wirklich aussagekräftiger End-to-End-Test.
Für mich ist deshalb klar: Testdatenmanagement ist keine Hilfsaufgabe des Testings, sondern ein zentraler Bestandteil einer professionellen Daten- und Business-Analyse.
Kommentare
Kommentare werden geladen ...
Kommentar verfassen