Stille Fehler in der Datenmigration: warum gute QA rückwärts prüft

Zeilen gezählt, Füllraten geprüft, Ladeprotokoll grün. Und trotzdem stehen falsche Werte im Zielsystem. Dieser Beitrag erklärt, warum klassische Mengenprüfungen nur laute Fehler finden, und zeigt eine Prüfmethode, die vom Ziel-Output rückwärts bis zur Quellzeile arbeitet.

Laute Fehler, stille Fehler

Laute Fehler machen sich bemerkbar: Der Ladelauf bricht ab, das Fehlerprotokoll füllt sich, die Zeilenzahl im Ziel weicht sichtbar von der Quelle ab. Genau darauf sind die üblichen QA-Instrumente geeicht: Mengenabgleich, Füllraten je Feld, Abbruchstatistik. Sie funktionieren, aber sie prüfen nur, ob Daten angekommen sind, nicht was angekommen ist.

Stille Fehler dagegen erzeugen keinen Alarm. Die Pipeline läuft durch, jede Zeile findet ihr Ziel, jedes Pflichtfeld ist gefüllt. Nur der Wert ist falsch. Ein Vertragskonto bekommt das Mahnverfahren des falschen Kundensegments, ein Vertrag ohne Endedatum landet mit dem Ende „heute" statt 31.12.9999 im System, eine Bedingungslogik greift für den Dann-Zweig, wo der Sonst-Zweig gemeint war. Formal ist alles korrekt, fachlich ist es falsch. Das fällt oft erst Wochen später auf, wenn die erste Mahnung rausgeht oder die erste Abrechnung scheitert.

Zwei Klassen von stillen Fehlern

Wer stille Fehler systematisch jagen will, muss sie erst sortieren. In der Praxis zerfallen sie in zwei Klassen, die unterschiedliche Werkzeuge brauchen:

Der Punkt dieser Trennung: Die Mehrheit der stillen Fehler gehört zu Klasse 1 und lässt sich vollautomatisch abfangen: billig, zuverlässig, bei jedem Lauf. Das teure fachliche Urteil hebt man sich für die Fälle auf, in denen es wirklich gebraucht wird. Wer stattdessen alles über manuelle Stichproben prüft, prüft am Ende gar nichts konsequent.

Wie solche Prüfungen im IS-U-Datenmodell konkret aussehen: ein Vertrag ohne Einzugsdatum in der Vertragstabelle EVER, ein Vertragskonto ohne Mahnverfahren in FKKVKP, oder ein Saldenabgleich der offenen Posten gegen DFKKOP, der nicht centgenau aufgeht. Alle drei sind deterministisch prüfbar, und alle drei rutschen durch jeden reinen Mengenabgleich.

Ein Semikolon kippt die Logik

Wie unscheinbar Klasse-1-Fehler sind, zeigt ein Fall aus einem Migrationsmandat: Eine Wenn-dann-Transformation erwartete ihre Parameter im Format Bedingung;Dann;Sonst. In einer einzigen Regel stand ein überzähliges Semikolon am Ende. Die Datei blieb formal valide, die Pipeline lief fehlerfrei durch, der Mengenabgleich stimmte. Aber der Sonst-Zweig war leer geworden, und ein ganzes Feldsegment erhielt den falschen Wert.

Kein Mensch findet so etwas beim Durchscrollen von zehntausenden Mapping-Zeilen. Eine automatische Grammatikprüfung („zählt die Zahl der Semikolons zur Transformation?") findet es in Sekunden, bei jedem Lauf, ohne dass jemand daran denken muss. Genau das ist der Maßstab für Klasse-1-Prüfungen: Sie dürfen nicht von Aufmerksamkeit abhängen.

Rückwärts prüfen: die Triangulation

Der Lint prüft vorwärts, bevor etwas läuft. Der eigentliche Bug-Finder arbeitet aber rückwärts: Er startet beim Ziel-Output und trianguliert über die Mapping-Regel zurück zum Quell-Input. Für jedes auffällige Feld läuft derselbe Entscheidungsbaum:

1. Output ansehen Was steht tatsächlich im Zielfeld? Nicht was stehen sollte, sondern was drinsteht.
2. Gegen die Regel halten Passt dieser Output zur hinterlegten Transformationsregel? Wenn ja: in Ordnung, nächstes Feld.
3. Input prüfen Wenn nein: Liegt es an der Quelle, etwa an einer leeren Spalte, einem fehlgeschlagenen Join, einem unerwarteten Format? Dann ist es ein Datenproblem und gehört zur Fachseite.
4. Bug deklarieren Wenn Input und Regel stimmen, der Output aber nicht: Es ist ein Fehler in Mapping oder Verarbeitung. Also reproduzieren, fixen, Prüfregel ergänzen.

Der Unterschied zur Vorwärtsprüfung ist fundamental. Vorwärts fragt man „ist die Regel wohlgeformt?", rückwärts fragt man „hat die Regel getan, was sie behauptet?". Nur die zweite Frage findet Fehler, die formal sauber aussehen. In der Praxis deckt diese Triangulation den Großteil der stillen Fehler auf, die Mengenabgleich und Füllraten monatelang übersehen haben.

Gate statt Meilenstein

Die beste Prüfmethode nützt wenig, wenn sie als Kalendereintrag organisiert ist. „QA-Woche vor dem Integrationstest" ist die schwächste Form der Absicherung: Sie hängt an Erinnerung und Disziplin, und sie kommt zu spät. Die Fehler stecken dann längst in ausgelieferten Ständen, auf denen Fachbereichstests und Folgemappings aufsetzen.

Robuster ist das Prinzip Gate statt Meilenstein: Jede Lieferung muss durch ein Prüfgatter, bevor sie weiterverarbeitet wird. Konkret heißt das: Der automatische Lint und ein Smoke-Test mit wenigen repräsentativen Zeilen je Migrationsobjekt, auf einen Blick plausibilisierbar, laufen bei jedem Lauf ab Tag eins. Die Rückwärts-Triangulation wird ereignisgesteuert ausgelöst: bei jeder neuen Datenlieferung und jedem neu gemappten Objekt, nicht nach Kalender. Und vor jeder Auslieferung steht ein Intent-Review der kritischen Objekte: Was wollte der Mapper erreichen, und tut die Regel das?

Viele gefundene Fehler sind kein Zeichen schlechter Arbeit – sie sind die direkte Folge davon, semantisch statt nur mengenmäßig zu prüfen.

Eine Definition-of-Done je Mapping macht das Gate verbindlich: Lint sauber, Smoke-Test plausibel, kritische Objekte im Intent geprüft. Erst dann gilt ein Stand als lieferbar. Wie das Zusammenspiel mit der Migration Workbench technisch aussieht, zeigt der Beitrag EMIGALL erklärt; welche fachlichen Fallen unabhängig von der QA lauern, beschreibt Datenmigration bei S/4HANA: typische Stolperfallen. Und weil der Wirtschaftsprüfer am Ende genau diese Nachvollziehbarkeit sehen will, lohnt der Blick auf auditfeste Datenmigration.