Data quality testing or data observability: which does a small data team need first?

Start with data observability on every table, then add data quality tests to the tables where a wrong value costs money. Freshness, volume, and schema monitors need no rules, and DataKitchen's 2026 Guide to DataOps Tests puts setup at about an hour. They can't see wrong values: a table can arrive on time, full size, and still be wrong.

By Chris Bergh Published October 20, 2026

Key points

Data observability watches table behavior over time (freshness, volume, schema), and data quality testing checks content against rules, so each one misses what the other catches.
A table can pass every observability check by arriving on time at the expected row count while holding wrong values, and pass every content rule while silently not having loaded since Tuesday.
Observability needs no hand-written rules, and DataKitchen's 2026 Guide to DataOps Tests says you can stand it up across bronze tables in about an hour, so it is the cheaper first step.
DataKitchen's coverage standard, in its 2026 Guide to DataOps Tests, is two to three tests per table for freshness, volume, and schema, at least two tests per column, and one custom test per significant business metric.
Neither layer stops bad data from reaching a report; a tripwire test between pipeline steps that fails the job is what stops it.

You can’t test what you haven’t looked at, and a small team hasn’t looked at most of its tables. That’s the case for doing observability first. It is cheap, it covers everything, and it tells you where to spend the expensive part, which is writing rules.

DataKitchen explains the split with a DevOps analogy: pets and cattle. Pets are the few tables you know by name. Cattle are the herd. You watch the herd for the cow that’s limping or missing, and you give the pets individual care.

	Data observability	Data quality testing
Watches	Freshness, volume, schema, drift	Values against rules
Scope	Every table, as a herd	The few critical tables
Who writes the rules	Nobody: monitors learn from history	You, plus whoever knows the business
Catches	Late loads, short loads, double loads, dropped columns	Negative amounts, broken keys, impossible combinations
Misses	Wrong values in a table that arrived on time	A table that stopped loading on Tuesday
Setup	About an hour, per the Guide to DataOps Tests	Grows with every rule

The bottom two rows are the point. A table can arrive on schedule at its usual row count with garbage in it. Another can pass every content rule because nothing new has landed since Tuesday. Process observability covers a third gap: the job that ran late, ran twice, or didn’t run.

The order that works for a small team

Week one: monitors on everything

Point table monitors at every schema you load. Freshness asks when the table last updated. Volume asks whether the right number of rows showed up: a table that normally grows by 1,000 rows and grows by 10 is a silent failure. Schema flags any added, dropped, or retyped column, with no prediction model needed. The Guide to DataOps Tests suggests letting a monitor learn a column’s shape over 90 days before you trust it, because a detector that hasn’t seen your weekends fires every Saturday.

Week two: pick your pets

Monitor results show which tables move, which are stale, and which break. Combine that with the obvious: the tables behind revenue, billing, and the report your VP reads. Keep the first list short enough that each table has a named owner.

Then: tests on the pets

Generate the structural tests from a profile (nulls, uniqueness, value ranges, patterns), then write the business rules by hand. DataKitchen’s coverage standard is two to three tests per table for freshness, volume, and schema, at least two per column, and one custom test per significant business metric.

Why generated tests alone aren’t enough

Generated tests learn what the data already looks like. In DataKitchen’s NYC taxi exercise, 62 generated tests all passed on a 300,000-row sample, because the minimum-fare test set its floor at negative $367, the lowest fare present. Seven business rules an AI wrote from the profile failed on that same sample, and again on the full month. A freshness and volume monitor alone would have passed that table too.

Neither one stops anything

Both layers find problems after the data has moved. To stop bad data, put a tripwire between two pipeline steps: a test task that exits with an error so the orchestrator never runs the next transform. Production keeps serving yesterday’s good data while somebody looks.

If you use DataOps TestGen, table monitoring sits in the same tool as profiling and test generation, so the first and third steps happen in one place. The order still holds. Monitors go everywhere. Rules go where they’ve earned it.

Frequently asked questions

Short answers to the follow-up questions people ask next.

What's the difference between data quality testing and data observability?

Data quality testing checks the content of data against rules: value ranges, formats, referential integrity, business logic. Data observability watches how tables behave over time: whether a table arrived, whether its row count moved, whether its schema changed. Testing answers whether the numbers are right. Observability answers whether the pipeline behaved. A small team needs both.

Why start with observability instead of tests?

Because observability needs no rules and covers every table at once. Freshness, volume, and schema monitors learn each table's normal behavior from its history, and you can stand them up in about an hour. The results show which tables are moving and which are already broken, so your later test-writing goes where the evidence points instead of where you guess.

Can data observability catch wrong values?

Mostly no. Freshness, volume, and schema monitors confirm a table arrived on time, at the expected size, with the expected columns. A negative fare or a duplicated customer passes all three. Catching wrong values takes data quality tests on content, including business rules written by someone who knows what the data means.

Which tables should get data quality tests first?

The few tables you know by name: the ones behind revenue, billing, regulatory reports, or the dashboard leadership reads every Monday. DataKitchen calls these pets, and the thousands of other tables cattle. Pets get specific hand-written rules and an owner. Cattle get monitors. A table graduates from cattle to pet when you learn it matters.

Do data quality tests and data observability stop bad data?

No. Both find problems, and by the time an alert arrives the bad data has usually moved downstream. Stopping it takes a tripwire: a test task between two pipeline steps that exits with an error, so the orchestrator never runs the next step and production keeps serving the last good data.

Try it on your own data

DataOps TestGen is free and open source. Profile a table and generate its tests this afternoon.

Install Open Source TestGen Request a Demo