A team wants to measure data quality. Which dimensions matter, and which tests actually catch problems?

The dimensions

• Completeness: are the expected records present. The most valuable and least tested, because it requires an independent expectation to compare against.
• Validity: do values conform to their type, range and format.
• Uniqueness: is the business key actually unique, which is violated more often than teams expect.
• Consistency: do related datasets agree — a total matching the sum of its parts, a foreign key resolving.
• Timeliness: did the data arrive when expected. A stalled pipeline produces stale data with no error, which nothing else detects.
• Accuracy: does the value match reality, which is the hardest and usually requires an external reference.

Which tests catch problems

The cheap structural ones catch the loud failures: not-null, uniqueness, referential integrity, accepted values. Worth having, and they catch the problems that would have been noticed anyway.

The ones that catch the quiet failures:

• Freshness assertions, since a pipeline that stopped produces no error and yesterday's data.
• Row-count anomaly detection against the historical pattern, which catches a partial load — the failure that structural tests pass and that changes every aggregate.
• Distribution checks on key columns, which catch an upstream semantic change: the same schema, different values, no error.
• Reconciliation against an authoritative source, which is the only test for accuracy and the only one that catches a transformation bug producing plausible values.

The failure mode of data testing

Too many tests on unimportant tables. A build running a thousand assertions across everything spends its time in the wrong place and produces a failure rate that trains the team to ignore it — the same dynamic as flaky tests and noisy alerts.

Concentrate on the datasets that decisions are made on, and accept that the rest are unmonitored.

The organisational requirement

A named owner per dataset and an agreed response to a failure. A test that fails and blocks nothing, with nobody accountable, is a report — and the question of whether a failing test should stop the pipeline or quarantine and continue must be decided per dataset, because both are defensible and the default is usually neither.