Name the data product and its grain
A revenue dashboard cannot be trustworthy if nobody knows what one row represents. For an orders table, define whether a row is an order, line item, payment, or status update. Write the expected primary key and explain whether historical corrections are allowed. Many apparent quality problems are disagreements about the model rather than corrupted data.
Choose one data product and document the decisions it supports. A daily finance summary may need stricter reconciliation than an exploratory clickstream report. Record the owner, expected delivery time, and consequences of stale or incorrect data. This makes it possible to prioritize meaningful checks instead of collecting a large number of low-value assertions.
Test structure and relationships first
Check required columns, parsable types, non-null identifiers, and uniqueness at the declared grain. Then validate relationships, such as every order customer_id appearing in the approved customer table. Include an explicit policy for deleted or anonymized customers so a legitimate privacy operation does not trigger an unexplained permanent failure.
Dbt recommends unique and not-null tests for model primary keys and tests for assumptions about source values. [1](https://docs.getdbt.com/faqs/Tests/recommended-tests) Even outside dbt, the principle is portable. Create a tiny fixture containing a duplicate order, a null key, and an orphan reference, and verify that each intended test detects its own failure.
Express business rules as violating rows
Write rules that return records needing investigation. For example, an order marked paid should have a payment reference, and a completed timestamp should not precede its creation timestamp under the documented time-zone convention. Be cautious with apparently obvious rules such as amount must be positive: credits and refunds may legitimately be negative.
Dbt data tests use queries that return failing records; a test passes when no violating rows are returned. [2](https://docs.getdbt.com/docs/build/data-tests) This pattern makes failures inspectable. Save enough identifiers and context for the owner to diagnose the issue, while controlling access to sensitive rows rather than copying them into unrestricted alerts.
Add freshness and distribution checks carefully
A table can satisfy every row-level constraint while containing yesterday's incomplete load. Check expected arrival time, coverage of the reporting period, and whether the upstream process declared completion. Distinguish event timestamps from ingestion timestamps so late-arriving business events do not look like a broken pipeline automatically.
Volume and distribution checks can reveal missing partitions or unusual values, but use context-aware thresholds. Weekends, holidays, launches, and migrations can produce legitimate shifts. Start with documented bounds and human review rather than implying that every deviation is corruption. Record known exceptions and their expiry dates so temporary allowances do not become permanent blind spots.
Decide which failures block publication
Classify tests by consequence. A duplicate primary key that doubles revenue may block the finance model. A small increase in optional profile-field missingness might create a warning. Specify the action, owner, and response expectation for each severity. An alert that nobody is assigned to handle is merely a notification stream.
Avoid silently dropping bad rows to make a test pass. Quarantine or correct them under a documented policy, and show their impact on reported totals. When a test is noisy, investigate the model or threshold rather than reflexively disabling it. The objective is dependable information, not a dashboard showing a reassuring number of green checks.
Test the tests and rehearse an incident
Introduce controlled failures into development fixtures and confirm that the pipeline fails or warns as designed. Check the alert destination, permissions, and diagnostic content. A test that never runs, targets the wrong table, or suppresses every failure provides no protection even if its SQL looks correct.
Rehearse one incident: a duplicate load arrives, the publication gate blocks output, the owner identifies the partition, the data is repaired, and a rerun reconciles totals. Record the timeline and improve the runbook. Your starter quality suite is complete when it catches meaningful errors and leads to a clear response, not when it reaches an arbitrary test-count target.
Sources & further reading
Last editorial review: 27 October 2026. Examples are educational, not live employer data or guaranteed outcomes.