Every ETL project needs the same core set of checks: did all the data arrive, was it transformed correctly, is it clean, and does the job behave when things go wrong? This page collects ETL testing test cases you can reuse on almost any pipeline — 35 ETL test cases examples grouped by category, each with how to test it and the expected result.
Use them as a starting checklist, then add cases for the business rules in your own mapping document. New to the topic? Start with what ETL testing is.
ETL Test Case Template
A good ETL test case has the same fields as any test case, plus the data details that make it repeatable:
| Field | Example |
|---|---|
| Test case ID | TC_ORD_005 |
| Title | Order amount converted to USD |
| Mapping rule | amount_usd = ROUND(amount × fx_rate, 2) |
| Source / target | src.orders → dw.fact_orders |
| Test data / precondition | Orders in EUR, GBP and USD loaded for 2026-10-01 |
| Steps (query) | Compare the rule applied to source with the target value per order_id |
| Expected result | 0 mismatching rows |
| Actual result / status | Pass / Fail + defect ID |
Data Completeness Test Cases
| ID | Test case | How to test | Expected result |
|---|---|---|---|
| TC01 | Source and target record counts match | Count rows in source (after filters) and target | Counts equal, or difference = rejected + filtered rows |
| TC02 | No records missing in target | Source key EXCEPT/MINUS target key | 0 rows |
| TC03 | No extra records in target | Target key EXCEPT/MINUS source key | 0 rows |
| TC04 | All columns loaded | Compare target columns with the mapping document | Every mapped column present and populated |
| TC05 | Measure totals reconcile | SUM of key amounts in source vs target, by day or month | Totals equal per period |
| TC06 | Rejected records accounted for | Source count = target + reject table + filtered | Equation balances |
Data Transformation Test Cases
| ID | Test case | How to test | Expected result |
|---|---|---|---|
| TC07 | Business rule applied correctly | Apply the rule to source in SQL and compare with the target column | 0 mismatches |
| TC08 | Concatenation / split | first_name + last_name = full_name | Values match, correct spacing |
| TC09 | Data type conversion | String dates and numbers converted to target types | No conversion errors, no lost precision |
| TC10 | Rounding and precision | Decimals at boundaries (e.g. .005) | Rounded per the rule, not truncated |
| TC11 | Date and time zone conversion | Timestamps near midnight and DST changes | Correct business date in target |
| TC12 | Lookup returns correct value | Source codes with a matching lookup row | Description/key from the lookup is loaded |
| TC13 | Lookup with no match | Source code missing from lookup | Default or "Unknown" value, or row rejected per spec |
| TC14 | Aggregation | Group source by the target grain and compare totals | Aggregates equal |
| TC15 | Derived / calculated column | Recalculate (e.g. age, margin) from source | Values match |
Data Quality Test Cases
| ID | Test case | How to test | Expected result |
|---|---|---|---|
| TC16 | Mandatory columns not null | COUNT where mandatory column IS NULL | 0 |
| TC17 | No duplicate business keys | GROUP BY key HAVING COUNT(*) > 1 | 0 rows |
| TC18 | Valid values only | Values outside the allowed list (status, country codes) | 0 rows |
| TC19 | Format checks | Emails, phone numbers, postcodes against a pattern | Invalid rows flagged or rejected |
| TC20 | No truncation | Source values longer than target column length | None, or rejected with a reason |
| TC21 | Whitespace and case trimmed | Leading/trailing spaces, mixed case where the rule standardises | Cleaned values in target |
| TC22 | Range checks | Negative quantities, future dates, ages > 120 | Handled per the data quality rules |
Integrity and Key Test Cases
| ID | Test case | How to test | Expected result |
|---|---|---|---|
| TC23 | No orphan fact rows | Fact foreign keys LEFT JOIN dimension, where dimension is NULL | 0 rows |
| TC24 | Surrogate keys unique and generated | Check uniqueness and that no source key is reused as surrogate | Unique, sequential/new keys |
| TC25 | Primary key constraint | Insert a duplicate key in test data | Load rejects or de-duplicates per spec |
| TC26 | Late-arriving dimension | Fact arrives before its customer record | Linked to inferred/unknown member, re-linked later |
Incremental Load and SCD Test Cases
| ID | Test case | How to test | Expected result |
|---|---|---|---|
| TC27 | Only changed rows processed | Change N source rows and run the delta | Exactly N rows inserted/updated |
| TC28 | Updates applied | Update a source attribute | Target reflects the new value (SCD1) or a new version (SCD2) |
| TC29 | Deletes handled | Delete a source row | Hard delete or soft-delete flag per design |
| TC30 | SCD2 versioning | Change a tracked attribute | Old row expired, new row current, one current row per key |
| TC31 | SCD2 no false versions | Change an untracked attribute | No new version created |
Load, Restart and Performance Test Cases
| ID | Test case | How to test | Expected result |
|---|---|---|---|
| TC32 | Re-run is idempotent | Run the same load twice for the same date | No duplicates, same result |
| TC33 | Restart after failure | Kill the job mid-load and restart | Completes with no missing or duplicate rows |
| TC34 | Empty or bad source file | Supply an empty file and a file with a missing column | Job fails safely with a clear error; target untouched |
| TC35 | Load within SLA | Run with production-like volume | Completes within the agreed time window |
More on each area: data validation in ETL, ETL performance testing and data warehouse testing.
ETL Test Scenarios (High-Level)
Test cases are specific checks; ETL test scenarios are the situations you need to cover. A typical scenario list for a new pipeline:
- First full load into an empty target.
- Daily incremental load with inserts, updates and deletes.
- Source sends duplicates or the same file twice.
- Source data violates rules (nulls, bad formats, unknown codes).
- A dimension member arrives after its facts.
- The job fails halfway and is restarted.
- Volume spikes to 2–3x normal.
- Schema change in the source (new, renamed or removed column).
- Report numbers compared with the warehouse after the load.
Interviewers love these as questions — see scenario-based ETL testing interview questions for model answers.
Worked Example: Turning a Mapping Rule into Test Cases
Mapping rule: load orders from src.orders to dw.fact_orders; exclude cancelled orders; city is upper-cased and trimmed; amount_usd = ROUND(amount * fx_rate, 2).
That one rule gives at least five test cases: count with the cancelled filter (TC01), missing keys (TC02), city transformation (TC07), currency rounding (TC10) and amount totals by day (TC05). The transformation check looks like this:
SELECT s.order_id, UPPER(TRIM(s.city)) AS expected_city, t.city AS actual_city, ROUND(s.amount * s.fx_rate, 2) AS expected_usd, t.amount_usd AS actual_usd FROM src.orders s JOIN dw.fact_orders t ON t.order_id = s.order_id WHERE s.status <> 'CANCELLED' AND (UPPER(TRIM(s.city)) <> t.city OR ROUND(s.amount * s.fx_rate, 2) <> t.amount_usd);
Expected result: 0 rows. More copy-ready queries are in ETL testing SQL queries.
Writing test cases from mapping documents is a core skill in our course, ETL Testing: From Beginners to Advanced, which covers SQL validation, data warehouse concepts and real-time testing scenarios. Preparing for interviews? The ETL testing interview practice tests include scenario-based and SQL questions with detailed answers.
Frequently Asked Questions
What are test cases in ETL testing?
ETL test cases are specific checks that prove data was extracted, transformed and loaded correctly, such as count checks, missing-record checks, transformation rule checks, null and duplicate checks, referential integrity and incremental load checks.
How do you write ETL test cases?
Start from the mapping document. For each target column and rule, write a test case with the source and target, test data, the SQL or steps to run, and the expected result. Add standard completeness, quality and integrity checks for every table.
What is the difference between ETL test cases and test scenarios?
A test scenario is a situation to cover, such as an incremental load with deletes. Test cases are the specific checks within it, such as verifying the deleted row is soft-deleted in the target.
How many test cases are needed for an ETL job?
It depends on the mapping, but most tables need at least the standard completeness, quality and integrity checks plus one test case per transformation rule. Critical financial tables usually get the most coverage.
Asim Noaman Lodhi
Certified Google Partner · QA Consultant · 12+ Years IT
QA consultant specializing in ETL testing and data quality. Trained 913+ students to transition into data testing roles through hands-on, real-world instruction.