Learning Objectives
By the end of this lesson you will be able to:
- Describe the PDM approach to Continuous Testing
- Explain the difference between technical validation and business acceptance testing
- Describe what a trial run programme looks like and what each run achieves
Continuous Testing
Continuous Testing (CT) is a PDM module - the ninth - but unlike the other modules, it is not a phase. It runs throughout the project.
Testing in PDM is not an event at the end of the build. It begins in the analytical phase (is the LDS list complete?), continues through GAM (are the mappings correct?), runs through each development release (do the ETL components work?), and culminates in a programme of trial runs using real data.
What Gets Tested
| Testing Type | What It Checks |
|---|---|
| LDS completeness | Have all legacy data stores been found? |
| Mapping correctness | Do the mapping rules accurately represent business requirements? |
| ETL unit tests | Do individual ETL components produce expected output? |
| Integration tests | Does the end-to-end pipeline produce the expected result? |
| Data profiling | What is the actual quality of extracted legacy data? |
| Transformation validation | Does transformed data make sense to BDEs? |
| Volume testing | Does the ETL complete within the required time window? |
| Target validation | Does loaded data pass target system business rules? |
| Fallback testing | Can the fallback procedure be executed within the fallback window? |
Trial Runs
Trial runs are full or partial executions of the migration pipeline using real legacy data. They are the primary mechanism for accumulating acceptance evidence.
Each trial run has a specific purpose and an acceptance threshold:
Development run (early)
- Purpose: First end-to-end test of the pipeline
- Volume: 10–20% of records
- Acceptance: The pipeline runs without critical errors; fallout is reviewed for new DQR items
Trial run 1 (mid-build)
- Purpose: DQR resolution validation and mapping review
- Volume: 50%+ of records
- Acceptance: BDEs review sample output and confirm business correctness; DQR metrics are reported
Trial run 2 (pre-dress rehearsal)
- Purpose: Full-volume validation and timing confirmation
- Volume: Full extract
- Acceptance: Record counts, timing within window, Priority 1 DQR items resolved
Dress rehearsal
- Purpose: Full cutover procedure under production conditions
- Volume: Full extract, all cutover steps executed
- Acceptance: Data Owner sign-off on the migrated data; timing within cutover window confirmed
Technical Validation vs. Business Acceptance
Technical validation is what the ETL team does: record counts, checksum validation, constraint checking, performance metrics. It confirms that the migration ran correctly.
Business acceptance is what the Data Owners and BDEs do: reviewing sample output, confirming that the data makes sense in a business context, signing the migration acceptance. It confirms that the migration produced the right result.
Both are necessary. A migration that passes all technical validation can still fail business acceptance - if the data is technically correct but business-wrong (e.g. all equipment maintenance frequencies have been set to a default that is not appropriate for the actual equipment).
Business acceptance testing is structured around the System Retirement Plan requirements: each BTR requirement that can be tested before go-live should be tested in the trial run programme.
Acceptance Criteria
Acceptance criteria for each trial run should be agreed before the run, not assessed after it. The criteria typically include:
- Maximum fallout rate by entity type and priority
- Maximum number of open Priority 1 DQR items
- Timing: ETL must complete within X hours
- Sample review pass: BDE confirms X% of randomly selected records are correct
- Target validation pass rate: Y% of loaded records pass all target business rules
When a trial run fails acceptance, it is not a failure of the migration - it is the test working. The evidence from the failed run feeds the next DQR resolution cycle.
Key Takeaways
- Continuous Testing runs throughout the project, not just in a final test phase
- Trial runs use real data and accumulate acceptance evidence across multiple increasingly complete runs
- Technical validation (ETL correctness) and business acceptance (business correctness) are distinct and both required
- Acceptance criteria must be defined before each trial run - not assessed afterwards
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 13 - Data Migration Testing