Testing is usually the phase everyone agrees is important and then quietly squeezes when the schedule gets tight. That's a costly trade — most of the defects that make it to production in a transformation program weren't caused by bad code, they were caused by test coverage that never accounted for the messy, real-world data and edge cases the new system would actually face.
Why Testing Gets Shortchanged
Testing sits at the intersection of two things transformation programs chronically underinvest in: data quality (test data needs to reflect real production messiness, not a clean sample) and schedule pressure (testing is usually the last phase before go-live, so it absorbs delays from every earlier phase). Neither problem is really about testing itself — but testing is where both problems become visible, usually too late to fix cheaply.
What a Real Testing Strategy Covers
Test level planning. Unit, integration, system, and user acceptance testing each catch different classes of defects — a strategy that only plans for UAT will miss integration failures until users find them in production.
Test data strategy. Test data needs to reflect the actual messiness of production data (nulls, duplicates, legacy formats), not a clean synthetic sample — otherwise validation passes in test and fails in production.
Defect triage process. A clear severity classification and an owner for each defect, so triage decisions don't quietly become "we'll fix it after go-live" by default.
Exit criteria, defined in advance. What percentage of test cases need to pass, and which defect severities block go-live — decided before testing starts, not negotiated under schedule pressure at the end.
Where This Fits in the AMIGA Framework
Testing sits primarily within the Technology dimension of the AMIGA Framework, but its quality depends heavily on the Data dimension (test data realism) and Governance dimension (defect triage authority and exit criteria enforcement) — another example of why the six dimensions function as one integrated system rather than separate workstreams.
Get a Structured Starting Point
The free Testing Strategy Template covers test level planning, defect management, and exit criteria in a ready-to-adapt format — a faster starting point than building a testing plan from scratch under deadline pressure.
Explore all free resources at theaiprojectmanager.ai →
Frequently Asked Questions
Should business users be involved earlier than UAT?
Involving business users in test case design, not just execution, tends to catch scenarios developers wouldn't think to test — waiting until UAT to involve them means catching those gaps very late.
How much test data is "enough"?
There's no universal number, but test data needs to include the messy edge cases (nulls, duplicates, legacy formats) present in production, not just clean happy-path records — volume matters less than realism.
What's the risk of skipping formal exit criteria?
Without exit criteria agreed in advance, the go/no-go decision at go-live becomes a negotiation under schedule pressure rather than an objective check, which is exactly when known defects quietly get waved through.
Instagram