ETL Testing Test Cases: 35 Examples and Test Scenarios

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:

FieldExample
Test case IDTC_ORD_005
TitleOrder amount converted to USD
Mapping ruleamount_usd = ROUND(amount × fx_rate, 2)
Source / targetsrc.orders → dw.fact_orders
Test data / preconditionOrders 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 result0 mismatching rows
Actual result / statusPass / Fail + defect ID

Data Completeness Test Cases

IDTest caseHow to testExpected result
TC01Source and target record counts matchCount rows in source (after filters) and targetCounts equal, or difference = rejected + filtered rows
TC02No records missing in targetSource key EXCEPT/MINUS target key0 rows
TC03No extra records in targetTarget key EXCEPT/MINUS source key0 rows
TC04All columns loadedCompare target columns with the mapping documentEvery mapped column present and populated
TC05Measure totals reconcileSUM of key amounts in source vs target, by day or monthTotals equal per period
TC06Rejected records accounted forSource count = target + reject table + filteredEquation balances

Data Transformation Test Cases

IDTest caseHow to testExpected result
TC07Business rule applied correctlyApply the rule to source in SQL and compare with the target column0 mismatches
TC08Concatenation / splitfirst_name + last_name = full_nameValues match, correct spacing
TC09Data type conversionString dates and numbers converted to target typesNo conversion errors, no lost precision
TC10Rounding and precisionDecimals at boundaries (e.g. .005)Rounded per the rule, not truncated
TC11Date and time zone conversionTimestamps near midnight and DST changesCorrect business date in target
TC12Lookup returns correct valueSource codes with a matching lookup rowDescription/key from the lookup is loaded
TC13Lookup with no matchSource code missing from lookupDefault or "Unknown" value, or row rejected per spec
TC14AggregationGroup source by the target grain and compare totalsAggregates equal
TC15Derived / calculated columnRecalculate (e.g. age, margin) from sourceValues match

Data Quality Test Cases

IDTest caseHow to testExpected result
TC16Mandatory columns not nullCOUNT where mandatory column IS NULL0
TC17No duplicate business keysGROUP BY key HAVING COUNT(*) > 10 rows
TC18Valid values onlyValues outside the allowed list (status, country codes)0 rows
TC19Format checksEmails, phone numbers, postcodes against a patternInvalid rows flagged or rejected
TC20No truncationSource values longer than target column lengthNone, or rejected with a reason
TC21Whitespace and case trimmedLeading/trailing spaces, mixed case where the rule standardisesCleaned values in target
TC22Range checksNegative quantities, future dates, ages > 120Handled per the data quality rules

Integrity and Key Test Cases

IDTest caseHow to testExpected result
TC23No orphan fact rowsFact foreign keys LEFT JOIN dimension, where dimension is NULL0 rows
TC24Surrogate keys unique and generatedCheck uniqueness and that no source key is reused as surrogateUnique, sequential/new keys
TC25Primary key constraintInsert a duplicate key in test dataLoad rejects or de-duplicates per spec
TC26Late-arriving dimensionFact arrives before its customer recordLinked to inferred/unknown member, re-linked later

Incremental Load and SCD Test Cases

IDTest caseHow to testExpected result
TC27Only changed rows processedChange N source rows and run the deltaExactly N rows inserted/updated
TC28Updates appliedUpdate a source attributeTarget reflects the new value (SCD1) or a new version (SCD2)
TC29Deletes handledDelete a source rowHard delete or soft-delete flag per design
TC30SCD2 versioningChange a tracked attributeOld row expired, new row current, one current row per key
TC31SCD2 no false versionsChange an untracked attributeNo new version created

Load, Restart and Performance Test Cases

IDTest caseHow to testExpected result
TC32Re-run is idempotentRun the same load twice for the same dateNo duplicates, same result
TC33Restart after failureKill the job mid-load and restartCompletes with no missing or duplicate rows
TC34Empty or bad source fileSupply an empty file and a file with a missing columnJob fails safely with a clear error; target untouched
TC35Load within SLARun with production-like volumeCompletes 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:

  1. First full load into an empty target.
  2. Daily incremental load with inserts, updates and deletes.
  3. Source sends duplicates or the same file twice.
  4. Source data violates rules (nulls, bad formats, unknown codes).
  5. A dimension member arrives after its facts.
  6. The job fails halfway and is restarted.
  7. Volume spikes to 2–3x normal.
  8. Schema change in the source (new, renamed or removed column).
  9. 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:

SQL
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
Written by

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.

4.5 Rating 913+ Students Google Partner 79 Lectures

Learn to Write and Run ETL Test Cases

SQL validation, data warehouse concepts and real-time testing scenarios. 79 lectures, lifetime access, $10.99.

Enroll Now — $10.99