Datentests sollten Annahmen festhalten, nicht nur Fehler melden

Ein Test sollte die Annahme benennen

Datenqualitätsprüfungen sind am nützlichsten, wenn sie eine Annahme dokumentieren, von der nachgelagerte Logik abhängt. „Diese Spalte ist nicht null“ ist hilfreich, wenn der Grund klar ist: Es kann ein Primärschlüssel, ein Join-Schlüssel oder ein Zeitstempel für inkrementelle Verarbeitung sein.

dbt beschreibt Data Tests als Assertions über Modelle und Quellen. Eingebaute Tests wie unique, not_null, accepted_values und relationships sind einfach, werden aber stark, wenn sie an Annahmen geknüpft sind, die einen Report, eine Pipeline oder eine Veröffentlichung brechen würden.

Mit der Fehlerwirkung beginnen

Vor einem neuen Test hilft die Frage, was ein Fehlschlag bedeutet:

1. Würden Zeilen durch einen Join verloren gehen?
2. Würde eine Metrik Datensätze doppelt zählen?
3. Würde ein nachgelagerter Verbraucher veraltete oder unvollständige Daten erhalten?
4. Wäre ein Wert syntaktisch gültig, aber fachlich falsch?
5. Sollte der Fehlschlag die Pipeline stoppen oder nur eine Warnung zur Prüfung erzeugen?

Great Expectations trennt Expectations von Validation Results und nutzt Severity, um geschäftliche Auswirkung auszudrücken. Diese Trennung ist wichtig: Nicht jedes Qualitätsproblem braucht dieselbe Reaktion. Ein fehlender Schlüssel, der ein Schema bricht, kann kritisch sein. Ein seltener Ausreißer in explorativen Daten kann eine Warnung sein.

Nützliche fehlerhafte Zeilen zurückgeben

Ein Datentest, der nur „fehlgeschlagen“ meldet, erzeugt Nacharbeit. Ein hilfreicher Test sollte genug Kontext zurückgeben, um den Fehler schnell zu untersuchen. Wenn ein Order-Status außerhalb der erlaubten Liste liegt, sollten die fehlerhaften Zeilen zum Beispiel Order-ID, Status, Quellsystem und Extraktionszeitpunkt enthalten, sofern diese Felder vorhanden sind.

So werden Fehler überprüfbar statt rätselhaft. Außerdem lässt sich besser unterscheiden, ob sich Quelldaten verändert haben oder ob Transformationslogik fehlerhaft ist.

Quellen und Outputs unterschiedlich testen

Source-Tests prüfen, was angekommen ist. Modelltests prüfen, was die Transformation garantiert. Beides wird gebraucht, beantwortet aber unterschiedliche Fragen.

• Source-Checks erkennen Upstream-Änderungen, bevor Transformationslogik sie verdeckt.
• Modell-Checks prüfen Schlüssel, Beziehungen, erlaubte Werte und Aggregationsannahmen nach der Transformation.
• Veröffentlichungschecks bestätigen, dass das ausgelieferte Artefakt in sich konsistent und aktuell ist.

Bei Datenpipelines sind Tests Teil des Vertrags zwischen Stufen. Ein erfolgreicher Build sollte mehr bedeuten als „SQL ist gelaufen“. Er sollte sagen, welche Annahmen geprüft wurden, welche Warnungen akzeptiert wurden und welche Ergebnisse sicher nutzbar sind.

Quellen

• dbt Data Tests zu Assertions, generischen Tests, Singular Tests, fehlerhaften Zeilen und Tests auf Quellen und Modellen.
• Great Expectations: Try GX Core zu Expectations, Validation Results, Severity und Kontext für fehlerhafte Datensätze.

Technische Quellen am 22. September 2026 geprüft. Dieser Beitrag ist allgemeine Datenqualitäts-Praxis, keine Aussage über eine konkrete Produktionspipeline.