Testdaten und Datenprozesse

Datenprozesse testen bedeutet, maschinell generierte Output-Daten gegen ein Soll-Ergebnis zu prüfen, das direkt aus der fachlichen Spezifikation abgeleitet wird. Dabei entstehen Äquivalenzklassen aus Fallunterscheidungen, die automatisch Testabdeckung erzeugen. Produktionsdaten decken erfahrungsgemäß rund 70 Prozent der Fälle ab; die restlichen 30 Prozent werden gezielt synthetisch ergänzt.

Das Wichtigste in Kürze

• Produktionsdatenbestände decken im Test nur rund 70 Prozent der Fallkonstellationen ab, weil seltene Grenzfälle dort schlicht nicht vorkommen und deshalb unentdeckt bleiben.
• Fachbereiche können Datenfehler in Verarbeitungsprozessen nur dann zuverlässig erkennen, wenn die Ergebnisse visuell und ohne SQL-Kenntnisse nachvollziehbar dargestellt sind.
• Automatisch generierte Soll-Ergebnisse auf Basis der fachlichen Spezifikation ersetzen manuelle Einzeltestfälle und liefern bei gleichem Aufwand eine höhere Testabdeckung.
• Das Regelwerk für den Datenvergleich kann gleichzeitig als Fachfeinspezifikation dienen, weil es die Abbildungslogik präzise und für Nicht-Techniker verständlich beschreibt.
• KI kann in diesem Kontext sinnvoll als Assistenz eingesetzt werden, etwa um SQL-Abfragen zu generieren und visuell darzustellen, nimmt dem Fachbereich aber nicht die inhaltliche Prüfverantwortung ab.

Datenfehler tauchen zu spät auf, wenn der Fachbereich nicht an die Daten kommt

Fehler in Datenverarbeitungsprozessen werden in vielen Unternehmen erst spät entdeckt, weil das Wissen über die Daten und der Zugriff auf sie auseinanderfallen. Die IT-Abteilung kommt technisch problemlos an die Daten heran, hat aber nicht das fachliche Verständnis, um inhaltliche Datenfehler zu erkennen. Der Fachbereich hätte das Verständnis, aber nicht den Zugriff.

In der Praxis führt das zu einem umständlichen Pingpong. Die Fachabteilung denkt sich einzelne Testfälle aus, bekommt dafür Daten geliefert und prüft sie manuell. Das deckt nur einen Bruchteil der möglichen Fälle ab und kostet viel Zeit.

Je später ein Fehler entdeckt wird, desto mehr Aufwand produziert er. Genau deshalb lohnt es sich, das Testen von Daten so früh wie möglich anzusetzen, idealerweise schon während der Entwicklung der Verarbeitungslogik.

Was unterscheidet Datenqualität vom Testen von Datenprozessen?

Datenqualität und das Testen von Datenprozessen sind zwei verschiedene Aufgaben. Beim reinen Datenqualitätsthema bekommt man Daten geliefert, ohne zu wissen, wie sie entstanden sind, und kann nur auf Plausibilität prüfen.

Ein Beispiel: Bei einer Liste lebender Personen ist ein Geburtsdatum von 1810 unwahrscheinlich. Mehr als diese Plausibilitätsprüfung ist nicht möglich, weil weder die Eingabedaten noch die Abbildungsvorschrift bekannt sind.

Beim Testen von Datenprozessen liegt dagegen eine fachliche Spezifikation vor, wie Eingabedaten in Ausgabedaten transformiert werden sollen. Hier lässt sich ein Soll-Ergebnis bilden und gegen das Ist-Ergebnis halten. Die Frage lautet dann: Wurden die Ausgabedaten entsprechend der fachlichen Spezifikation produziert?

Soll-Ergebnisse systematisch generieren statt Einzeltestfälle bauen

Der wirksamere Ansatz ist, Soll-Ergebnisse systematisch zu erzeugen und vollständig mit den Ist-Ergebnissen zu vergleichen, statt einzelne Testfälle von Hand zu definieren. Grundlage dafür sind fachliche Regeln, die die Fachabteilung ohnehin festlegen muss, um die Datenabbildung zu beschreiben.

Aus diesen Regeln lässt sich automatisch ein Soll erzeugen, das man sogar auf den vollständigen Produktionsdatenbestand anwenden kann. Jede Zeile, jede Spalte lässt sich so prüfen.

Der Aufwand bleibt dabei überschaubar. Wer dieselbe Abdeckung mit manuellen Testfällen erreichen will, braucht mindestens genauso lange und kommt trotzdem auf eine schlechtere Testqualität, weil er gar nicht so viele Fälle abbilden kann.

Produktionsdaten decken nur einen Teil der Fälle ab

Wendet man die automatische Soll-Generierung auf den Produktionsbestand an, deckt das in der Praxis oft nur etwa 70 Prozent der relevanten Fälle ab. Die fehlenden 30 Prozent müssen ergänzt werden, um eine weitreichende Abdeckung zu erreichen.

Der Grund liegt in der fachlichen Logik selbst. Durch die Fallunterscheidungen bilden sich auf natürliche Weise Äquivalenzklassen. Gibt es für eine Fallunterscheidung keine passenden Daten, etwa für den Fall “Alter größer 90”, weiß man nicht, ob der Prüfling in diesem Fall korrekt arbeitet.

Solche Lücken fallen erst auf, wenn später ein realer Fall eintritt und schiefläuft. Wer nur Produktionsdaten nutzt, testet diese Konstellationen schlicht nicht. Deshalb reichert man die anonymisierten 70 Prozent aus der Produktion gezielt um die fehlenden Konstellationen an.

Für den laufenden Test baut man sich daraus ein Test-Set, das alle Fallkonstellationen mit je einem Vertreter abdeckt und schnell durchläuft. Den vollen Bestand prüft man eher als gesonderte Qualitätssicherung des Produktionsbestands.

Es ist keine Doppelimplementierung, wenn man nur das Mapping nachbildet

Ein verbreiteter Einwand gegen Datenvergleiche lautet, man baue das System ein zweites Mal nach und schleppe damit dieselben Fehlerquellen ein. Beim hier beschriebenen Ansatz trifft das nicht zu, weil nur die fachliche Abbildungsvorschrift nachgebildet wird, nicht das System.

Die meisten Mappings sind umfangreich, aber nicht komplex. Es geht um Fallunterscheidungen: Wenn dies, dann jenes, sonst etwas anderes. Solche Logik lässt sich direkt aus der Spezifikation abbilden, ohne sich um Performance oder andere Nebenbedingungen kümmern zu müssen.

Der Aufwandsunterschied ist deutlich. Wo das Generieren des Testergebnisses einen Tag braucht, ist die Implementierung des Systems mit mehr Leuten ein bis zwei Wochen beschäftigt. Man macht nicht mehr, sondern vor allem vieles nicht.

Wir bauen nicht das ganze System nach. Wir nutzen die Spezifikation und bilden direkt mit der Spezifikation die Abbildungsvorschrift nach. Es geht nicht darum, wann genau was abzulaufen hat, sondern wir testen nur das Mapping. Joshua Claßen

Für wirklich komplexe Berechnungen gilt ein anderer Weg. Bei einer komplexen Simulation holt man verifizierte Soll-Ergebnisse aus einer unabhängigen Quelle und vergleicht mit einer definierten Toleranz.

Daten aus vielen Liefersystemen müssen vor dem Test zusammengeführt werden

In heterogenen Systemlandschaften gibt es selten nur ein Eingabesystem. Mehrere Liefersysteme speisen Daten ein, die harmonisiert und an eine zentrale Schnittstelle gegeben werden müssen.

Ein Beispiel ist eine Geldwäsche-Prüfung auf Transaktionsdaten. Die Eingabedaten aus den verschiedenen Liefersystemen werden zusammengebracht und an diese Schnittstelle geliefert. Genau dieser Prozess der Zusammenführung lässt sich mit denselben Prinzipien testen wie ein einzelnes Mapping.

Warum Datenvergleiche Toleranzen brauchen

Ein Datenvergleich ist nicht immer ein exakter Eins-zu-eins-Abgleich. In bestimmten Fällen sind kleine Abweichungen fachlich akzeptabel und müssen über definierte Schwellen toleriert werden.

In einem Handelssystem bei Banken werden etwa Cashflows algorithmisch generiert. Durch numerische Eigenschaften kann dasselbe Ergebnis je nach Reihenfolge der Rechenoperationen um ein, zwei Cent abweichen. Solche Abweichungen sind unkritisch, solange sie sich nicht über akzeptable Schwellen hinaus hochschaukeln.

Toleranzen betreffen nicht nur Zahlen. Auch bei Textfeldern kann eine Toleranz sinnvoll sein, etwa wenn Groß- und Kleinschreibung beim Vergleich keine Rolle spielen soll.

Fachliche Regeln, die zugleich die Spezifikation sind

Das Regelwerk, mit dem das Soll generiert wird, kann zugleich die Fachfeinspezifikation sein. So fallen Test-Grundlage und fachliche Vorgabe in einem Artefakt zusammen, statt in getrennten, voneinander abweichenden Dokumenten zu leben.

Eine solche Regel braucht kein technisches, sondern nur natürliches Verständnis. Ein Beispiel für eine Namensregel:

• Sind Vorname und Nachname nicht leer, werden beide separat ausgegeben.
• Ist nur der Vorname ausgefüllt, wird nur der Vorname ausgegeben.
• Ist nur der Nachname ausgefüllt, wird nur der Nachname ausgegeben.
• In allen anderen Fällen wird ein Fehler ausgegeben.

Dieser Ansatz hat einen doppelten Nutzen. Wenn der Fachbereich früh die Ergebnisse der definierten Logik sieht, erkennt er sofort, wenn eine Fallunterscheidung fehlt. Eine Implementierung kann korrekt zur Spezifikation sein und trotzdem falsche Ergebnisse liefern, weil die Spezifikation selbst lückenhaft ist.

Visualisierung bringt Fachbereich und IT auf eine Wellenlänge

Datenvergleiche müssen visualisiert sein, damit der Fachbereich sie versteht und beide Seiten am selben Objekt arbeiten können. Ein technisch ausgedrücktes Dokument trennt Fachbereich und IT, eine sichtbare Definition des Datenvergleichs verbindet sie.

Beim Datentesten wiederholen sich die Muster. Der Test heißt immer, ein Soll mit einem Ist zu vergleichen. Die meisten Daten liegen tabellarisch vor, lassen sich aber auch als XML oder JSON vergleichen. Weil diese Muster ständig vorkommen, lassen sie sich mit Low-Code-Komponenten schneller und einfacher umsetzen, als sie jede Abteilung neu zu programmieren.

Genau diese Redundanz beobachtet man bei großen Bankkunden mit vielen Abteilungen. Jede baut ihren eigenen CSV-Vergleicher, jede erfindet das Rad neu. Textverarbeitung schreibt sich auch niemand selbst.

Auch wer SQL kann, profitiert von einer guten Visualisierung. Sie lässt sich schneller erfassen als reiner Code. Wer von 100 Spalten 99 abfragen will, muss in SQL alle 99 angeben, in einer grafischen Oberfläche klickt man die eine Spalte weg.

KI macht das Testen effizienter, nicht überflüssig

KI ersetzt die Arbeit am Datentest nicht, sie beschleunigt sie. Ein KI-System kann Vorschläge machen, etwa Fallunterscheidungen in Intervallen vorgeben oder einen Test entwerfen, aber das Ergebnis muss überprüfbar bleiben.

Genau hier ist die Visualisierung der Hebel. Generiert eine KI nur Code, muss man Code lesen können, um den Vorschlag zu verifizieren. Ist das Ergebnis dagegen visuell dargestellt, kann auch jemand ohne tiefe Coding-Kenntnisse schnell beurteilen, ob es passt, und den Rest selbst korrigieren.

Bei sensiblen Unternehmensdaten gibt es eine harte Grenze. Solche Daten gehen nicht an einen externen Dienst ins Internet. Die Entwicklung geht deshalb in Richtung effizienterer, lokal nutzbarer Sprachmodelle, mit denen sich aus einer natürlichsprachlichen Anforderung SQL und daraus eine visualisierte No-Code-Abfrage erzeugen lässt.

Daneben taugt KI als Co-Pilot für die Bedienung selbst. Sie kann Vorschläge geben, wie ein Tool zu verwenden ist, oder eine Frage beantworten, wie sich eine bestimmte Aufgabe am besten lösen lässt. Eine vollständig unabhängige Aussage “hier ist mein System, teste es” liegt dagegen nicht in naher Zukunft.