Most data teams test at the end of the line. A check runs against the gold table right before the report refreshes. By then the bad row has been joined, aggregated, and cached, and the test can tell you something is wrong but not which step did it.
Shifting left moves the check to where the row came in.
Two directions, two pipelines
DataKitchen’s Flip the Script post draws a data operation as two lines that cross. Data flows left to right through production. Code and configuration flow top to bottom, from development into production. Each line gets its own shift.
| Shift left | Shift down | |
|---|---|---|
| What flows | Data, through the production pipeline | Code and configuration, from development to production |
| Where tests move | Toward the source: ingestion and each transform step | Into the deployment path, before a change merges |
| What it catches | Bad source data and broken tools mid-run | A change that silently moves a number |
| Kind of test | Schema, type, range, row-count and distribution checks; tripwires that stop the line | Regression and impact tests on realistic test data |
| What it protects | The data you already have | The data your next deployment will produce |
The manufacturing name for the left half is the Andon cord: any worker can stop the line when they see a defect. In a pipeline, that’s a test between two steps that exits with a non-zero code, so the orchestrator never runs the next transform and production keeps the last known good data.
Why earlier is cheaper
The 1:10:100 rule, from quality experts George Labovitz and Yu Sang Chang, prices a bad record by where you catch it. Prevention at the source costs about $1. Remediation after the data is created costs about $10. Failure, once the data reaches a customer and drives a decision, costs about $100.
The Flip the Script post has an example, sorted here into the rule’s three tiers. A source system starts sending timestamps in a different time zone without warning.
| Where you catch it | 1:10:100 tier | What the fix involves |
|---|---|---|
| At ingestion, by a schema or range test | 1 | Update one transformation rule |
| In the warehouse, after daily rollups ran | 10 | Find every affected calculation and regenerate historical aggregates |
| In a report someone already acted on | 100 | All of the above, plus explaining to the business why last week’s numbers were wrong |
The bug is identical in all three rows. Only the place you found it changed.
Where shift left sits among the four places to test
DataKitchen’s Guide to DataOps Tests names four places a team tests data. Three of them run along the production line, and that’s the shift-left half. The fourth is the deployment path, and that’s shift down.
| Place to test | Direction |
|---|---|
| Data quality on source data | Left |
| Observability at ingestion: freshness, volume, schema | Left |
| Tripwires between transformation steps in production | Left |
| Regression tests on deployment to production | Down |
The same null check does a different job in each spot. A post on four critical processes makes the point: one test becomes a quality metric, an alert, a tripwire, or a regression test, depending on what happens when it fails.
The honest obstacle is volume
Shifting left means testing bronze tables and raw feeds, and there are a lot of them. The test coverage guide sets a floor of two tests per table plus tests on every column. The Guide to DataOps Tests puts a mid-size Medallion architecture at roughly 5,000 tests. Nobody hand-writes 5,000 tests and keeps them current.
That’s why most teams still test at the end. DataKitchen estimated in its September 2025 post that about 80% of data teams rely on hope-based testing in development, with no automated validation before changes reach production.
So generate the routine tests from a profile of each table and keep people for the business rules. DataKitchen’s open-source DataOps TestGen does the generating, and DataKitchen sells it, so weigh that. For where to begin on a small team, see which checks to set up first.