Michael Kutz
Quality Engineer at REWE digital, Conference Speaker about QA & Agile, Founder of Agile QA Cologne meetup, Freelance QA Consultant
Entropy Data
Consumer-Driven Contracts für Daten
Was die Datenwelt von der Testpyramide lernen muss – und umgekehrt
Michael Kutz OOP 2027 Februar 2027
OOP 2027 · 02.–05.02.2027
Montag, 9:00 Uhr
● ● ● dashboard.beispiel-shop.de/umsatz
Umsatz-Dashboard
● Zuletzt aktualisiert: vor 2 Minuten
Umsatz heute
48.230 € ▲ 12 %
Bestellungen
1.284 ▲ 8 %
Ø Warenkorb
37,55 € ▲ 3 %
OOP 2027 · 02.–05.02.2027
Drei Wochen später
● ● ● dashboard.beispiel-shop.de/umsatz
Umsatz-Dashboard
● Zuletzt aktualisiert: vor 21 Tagen
Umsatz heute
— keine Daten
Bestellungen
— keine Daten
Ø Warenkorb
— keine Daten
⚠ Query failed
column "order_total" does not exist
OOP 2027 · 02.–05.02.2027
Was ist passiert?
Team Checkout
besitzt Service & Datenbank
order_total → total_amount
✅ Eigene Tests grün · deployed
Daten-Pipeline
liest die Tabelle – nachts um 3
⚠ Query scheitert – ohne Alarm
📊 Dashboard – leer
🤖 ML-Modell – veraltet
👥 Nachbarteam – blockiert
Tag 0 – deployed, alles grün
Tag 1–20 – niemand merkt etwas
Tag 21 – der Fachbereich ruft an
⚠ Kein Vertrag · kein Test · kein Alarm
OOP 2027 · 02.–05.02.2027
Hi, ich bin Micha
🚀Staff Engineer @ Entropy Data
✅15+ Jahre Software-Qualität & Testing
🔧Open Source: ApproveJ, Stubit, Shakespeare
🎤Sprecher auf OOP, Agile Testing Days & Co.
🐛Bugs: fixen vermeiden mit und ohne KI
OOP 2027 · 02.–05.02.2027
Testdaten ≠ Daten testen
Testdaten
Daten für Tests
- Generieren, anonymisieren, verwalten
- Eigene Disziplin mit ISTQB/GTB-Lehrplan
- Sichert die Qualität der Software
→ Heute nicht unser Thema
≠
Daten testen
Tests für Daten
- Schema, Semantik, Frische, Vollständigkeit
- Die Daten selbst sind das Produkt
- Sichert die Qualität der Daten
→ Darum geht es heute
OOP 2027 · 02.–05.02.2027
Was ist eigentlich ein Datenprodukt?
Service mit API
Zweck
Geschäftsprozesse ausführen
Schnittstelle
Schmale API – definierte Operationen
Typischer Zugriff
Ein Datensatz, aktueller Zustand
Die Tabelle ist …
Implementierungsdetail – gekapselt
Konsumenten
Andere Services & Frontends
vs.
Datenprodukt
Zweck
Fragen beantworten – auch die von morgen
Schnittstelle
Query-Interface – SQL, Topics, Files
Typischer Zugriff
Millionen Zeilen, Historie, Joins
Die Tabelle ist …
Die Schnittstelle selbst – bewusst veröffentlicht
Konsumenten
Analysten, Dashboards, ML, KI-Agenten
Das Schema ist die API des Datenprodukts – und jede Schnittstelle braucht einen Vertrag.
OOP 2027 · 02.–05.02.2027
Risk Storming: eine Karte wird zum Deck
Risk Storming: ein Workshop-Format aus dem agilen Testen – das Team diskutiert am Kartendeck (TestSphere), welche Qualitätsaspekte für sein Produkt die riskantesten sind. Eine der Karten heißt „Data“:
✓
Performance
✓
Security
✓
Usability
◆
Data
…
Für Datenprodukte fächert sich „Data“ auf in:
01
Schema-Stabilität
Spalten & Typen – bricht wie eine API
◆
02
Aktualität
Wann kam die letzte Lieferung?
◆
03
Vollständigkeit
Alle Zeilen da? Wie viel null ist okay?
◆
04
Validität
Wertebereiche, Formate, Plausibilität
◆
05
Konsistenz
Passen die Zahlen zusammen – auch produktübergreifend?
◆
06
Semantik
Netto oder brutto? Bedeutung ist Teil der Qualität
◆
Genau diese Karten schreibt der Data Contract fest – maschinenlesbar und testbar.
OOP 2027 · 02.–05.02.2027
Rückblende: zwei Pipelines, ein Vertrag
Zwischen Services lösen wir das so: Der Konsument schreibt seine Erwartungen als Vertrag auf – und beide Pipelines testen dagegen. Schritt für Schritt:
Consumer-Pipeline · Team Dashboard
Build & Unit-Tests
wie immer
Contract-Test
gegen einen Mock des Providers
Vertrag publizieren
an den Pact Broker
can-i-deploy ✓
dann Deploy
Pact Broker
verwahrt alle Verträge
Provider-Pipeline · Team Checkout
Build & Unit-Tests
wie immer
Verträge verifizieren
gegen alle Konsumenten-Verträge
Ergebnis melden
zurück an den Broker
can-i-deploy ✓
dann Deploy
Der Vertrag verbindet beide Pipelines – keiner deployt, was den anderen bricht.
OOP 2027 · 02.–05.02.2027
Consumer-Driven Contracts für Daten
Fast dieselben Pipelines – mit einem Unterschied: Der Contract entsteht nicht in der Pipeline, sondern vorab und gemeinsam. Die Pipelines testen nur noch dagegen.
Consumer-Pipeline · Dashboard-Team
Build & Tests
wie immer
datacontract test ✓
prüft die gelieferten Daten
Ergebnis melden
zurück an die Registry
Deploy ✓
nur bei grünem Contract
Vorab · gemeinsam
Contract vereinbaren
Producer & Consumer, contract-first
Contract-Registry
verwahrt alle Contracts
Producer-Pipeline · Datenprodukt-Team
Build & Transform
z. B. dbt run – wie immer
datacontract test ✓
Schema & Qualität aller Contracts
Ergebnis melden
zurück an die Registry
Deploy ✓
nur bei grünen Contracts
Bricht das Schema, stoppt die Pipeline – nicht das Dashboard.
OOP 2027 · 02.–05.02.2027
So weit trägt die Analogie.
Jetzt wird es ehrlich.
Drei Dinge funktionieren bei Daten grundlegend anders.
OOP 2027 · 02.–05.02.2027
Wo die Analogie bricht
01
Kein Aufrufer, den du kontrollierst
Ein Service kennt seine Aufrufer – bei Pact meldet sich jeder Consumer mit seinem Vertrag an.
Daten werden abgefragt: Jeder mit Leserechten kann konsumieren – und niemand merkt es.
→ Konsumenten sichtbar machen ist Teil des Problems: Registry statt stiller SELECTs.
02
Kein Rollback für die Vergangenheit
Ein kaputtes Deployment rollst du zurück – der nächste Request ist wieder korrekt.
Drei Wochen falsche Daten stecken in jedem Downstream-System, Report und trainierten Modell.
→ Prävention schlägt Heilung: Der Test vor dem Deployment ist alles.
03
„Korrekt“ ist Semantik, nicht Typ
Bei einer API prüft der Compiler den Typ – total: Number ist entweder da oder nicht.
total = 47.11 ist ein valider Float – aber netto oder brutto? Mit oder ohne Storno?
→ Bedeutung gehört in den Contract: Definitionen, Semantik, Geschäftsbegriffe.
OOP 2027 · 02.–05.02.2027
Inhalts-Layout: drei Spalten
Spaltentitel eins
Kurze Einordnung des Themas in ein bis zwei Sätzen.
- Erster Punkt mit einer Kernaussage
- Zweiter Punkt, gern etwas länger über zwei Zeilen
- Dritter Punkt
Spaltentitel zwei
Kurze Einordnung des Themas in ein bis zwei Sätzen.
- Erster Punkt mit einer Kernaussage
- Zweiter Punkt
- Dritter Punkt
Spaltentitel drei
Kurze Einordnung des Themas in ein bis zwei Sätzen.
- Erster Punkt mit einer Kernaussage
- Zweiter Punkt
- Dritter Punkt
OOP 2027 · 02.–05.02.2027
Statement-Layout
Warum testen wir Daten nicht wie Code?
OOP 2027 · 02.–05.02.2027
Vergleich: zwei Karten
Software-Welt
- Consumer-Driven Contracts mit Pact
- Vertrag lebt am Port, Tests in der Pipeline
- Bruch wird vor dem Deployment erkannt
Daten-Welt
- Data Contracts mit ODCS
- Contract-Tests mit der Data Contract CLI
- Schema-Bruch wird vor dem Deployment erkannt
DEMO
OOP 2027 · 02.–05.02.2027
Danke! Fragen?
Ihr wollt mehr wissen?
Schreibt mir
michael.kutz@entropy-data.com
Folien & mehr von mir
michael-kutz.de
Probiert Data Contracts aus
Auf www.entropy-data.com die 1-Click-Demo starten
Consumer-Driven Contracts für Daten
By Michael Kutz
Consumer-Driven Contracts für Daten
Viele Teams würden keinen Service ohne Tests ausliefern – doch dieselben Teams liefern täglich Daten an Dashboards, ML-Modelle und andere Teams: ohne Vertrag, ohne Test, ohne Garantie. Nach 15 Jahren in der Software-Qualität bin ich in die Datenwelt gewechselt und habe festgestellt: Sie steht dort, wo Testing vor 15 Jahren stand. Der Vortrag schlägt die Brücke – wie sich Consumer-Driven Contracts, Contract-Tests und Ports-and-Adapters-Denken auf Datenprodukte übertragen lassen, mit Data Contracts und ODCS. Und wo die Analogie bewusst bricht. Zielpublikum: Jeder, der mit Daten arbeitet oder von ihnen abhängtKeywords: Data Engineering, Contract Testing, ODCS Voraussetzungen: keine Level: Introductory Extended Abstract: Wir würden keinen Service ohne Tests in Produktion bringen. Wir kennen Consumer-Driven Contracts, wir mocken Ports und Adapter, wir versionieren APIs sorgfältig. Doch dieselben Teams liefern täglich Daten an nachgelagerte Konsumenten aus – an Dashboards, ML-Modelle, oder andere Teams – ganz ohne Vertrag, ohne Test, ohne Garantie. Bricht ein Schema, merkt es niemand, bis das Dashboard leer bleibt. Ich habe 15 Jahre lang an der Qualität von Software gearbeitet und bin dann in die Datenwelt gewechselt. Die ernüchternde Erkenntnis: Die Datenseite steht ungefähr dort, wo Software-Testing vor 15 Jahren stand. Die gute Nachricht: Wir müssen das Rad nicht neu erfinden.
