Each card shows who executes, who signs off, entry / exit criteria, deliverables, and the most common pitfall.
| Level | Full name | The question it answers | Executed by |
|---|---|---|---|
| Unit | Unit Test | Does each piece of code work on its own? | SI developers |
| FAT | Functional Acceptance Test | Does each configured function work as designed? | SI Tester, per sprint |
| Mini-BAT | Mini Business Acceptance Test | Are the benefits still on track, checked early? | Benefit Owners |
| SAT | System Acceptance Test | Does the whole system hang together after build? | SI functional consultants / test team (SI Test Lead owns and signs) |
| SIT | System Integration Test | Does it still work with the other systems connected? | SI + client testers, co-run by Client Test Manager + SI Test Lead (exit signed by Client Test Manager + Solution Architect) |
| Pre-UAT | Pre-UAT readiness check | Is the UAT environment ready for the business to test in? | Client Test Manager |
| UAT | User Acceptance Test | Can real users run their real business processes end to end? | End users |
| BAT | Business Acceptance Test | Does it deliver the benefits the business signed up for? | Benefit Owners + Executive Sponsor |
| NFT | Non-Functional Test (parallel) | Is it fast, secure and resilient enough for production? | IT Ops Lead |
Sign-off chains depend on knowing who does what — and who does NOT do what. The most common testing failure on ERP programmes is muddled roles. Each tile carries reports-to, active stages, responsibilities, sign-off authority, and the common mistake.
Two named Client-side architecture roles sit alongside the Solution Architect. Both report to the Solution Architect; both have testing involvement (integration test scope, master data integrity, cutover data state) but are programme-wide roles, not testing-specific. They do not count in the fourteen testing tiles above — they sit in the broader role catalogue.
Architecture roles sit Client-side only. SI counterparts are the SI Solution Architect, SI Technical Lead and SI Data Migration Lead (already in the testing role catalogue above).
The line is field-level vs process-level. Get this wrong and your acceptance evidence doesn't reflect real user experience.
Field-level / configuration-level. Tests that individual user stories or configurations work as designed.
Process-level / business-flow. Tests end-to-end business journeys.
If a tester is checking field X accepts data type A → that's FAT.
If a tester is walking through "I'm a stock controller, show me my Tuesday morning workflow" → that's UAT.
Blocks all testing or renders the area untestable. Ship-stopper.
Important function broken but business can continue with manual or alternative steps.
Inconvenience but not blocking. Logged with post-go-live fix plan.
Typos, alignment, label inconsistencies. Backlog candidates.
Go-live rule: zero P1; zero P2 unless a workaround is agreed and documented; P3 within published ceiling, with post-go-live fix plan; P4 in backlog. P2 workarounds must be agreed by the Design Authority and Process Owner and recorded in the Test Exit Report — no grey area.
A change made to fix or add one thing can quietly break something that already worked. Regression testing re-runs tests that previously passed to catch exactly that.
Regression is not a phase — it runs continuously across the pipeline, with different intensity at different stages. Risk-driven, not ceremonial. The regression pack is a permanent operational capability that runs through every release, patch and config change for the life of the platform — not a Build-phase activity that ends at go-live.
Same discipline, different intensity. Every phase answers the same three questions: what triggers regression, what gets re-run, and what shape the re-run takes. The shape varies by design — sprint loops in Build, three cycles in SAT and SIT, daily targeted runs in UAT, single proven passes at Pre-UAT and BAT, and risk-based runs for the life of the platform.
| Phase | Regression scope | Owner |
|---|---|---|
| Build (S13) — per sprint | Regression here is the sprint loop itself: each sprint re-runs the passed tests from previous sprints alongside FAT on the new stories (dev/test environment). Smoke-test for tightly-scoped UI tweaks; full re-run for changes to shared logic. No separate cycle structure — the sprint cadence is the cycle. | SI Tester / SI Test Team |
| SAT (S13/14 boundary) | SAT establishes the regression pack (SI test environment). Three cycles plus a sanity test — defects found in cycle one are fixed and re-proven in cycles two and three; the sanity run confirms the final state. Pack is the deliverable carried forward. | SI Test Lead |
| SIT (S14) | SAT regression pack re-run with third parties connected (integrated test environment) — same three-cycle shape as SAT, usually compressed: full pass, prove the fixes, prove convergence. Catches regression introduced specifically by integration changes. | Client Test Manager (owns) + SI Test Lead |
| Pre-UAT (S14) | Single spot-check pass on the UAT environment to confirm parity with SIT. Not a phase in its own right — a readiness confirmation before users arrive. | Client Test Manager |
| UAT (S14) | Daily targeted regression on the areas touched by that day’s defect fixes (UAT environment) — a short, impact-based cycle, not the full pack. Where the pack is automated it runs overnight in addition; full manual pack re-runs happen at cycle boundaries and exit, not nightly. | Client Test Manager + Defect Manager |
| BAT (S14) | One proven pass of the pack at BAT entry (production-shaped data environment) — confirming the system the Benefit Owners and Executive Sponsor are assessing still passes everything it ever passed. | Client Test Manager |
| Post-go-live (S17 onward) | Risk-based for the life of the platform: the automated pack runs against every patch and config change (production); a full run — automated core plus manual critical processes — before each platform update (e.g. D365 release waves). Permanent capability with a named owner — not a Build-phase activity that ends at go-live. | IT Operations + Platform Owner |
Sign-off is non-transferable. Regression-pack sign-offs at each phase are signed by the named owner only. If the named role is unavailable on the day, the sign-off waits — it does not delegate down. Substituted sign-off on regression cycles is a common cause of post-go-live disputes about whether a fix was actually validated against the wider pack.
Three cycles, two weeks (SAT and SIT). NFT runs in parallel alongside them on its own track — same three-cycle shape (test → prove fixes → prove convergence) applied to performance, security and resilience, converging on the same exit.
UAT runs differently: users execute daily, targeted regression follows the day’s fixes, one proven run before exit — no formal cycle structure.
Cycle 1 finds the defects. Cycle 2 proves the fixes — and that they broke nothing else. Cycle 3 proves the trend: defect arrivals falling toward zero. Exit on evidence of convergence, not a snapshot.
The cycles interleave with the phase’s normal execution — plan roughly two weeks inclusive for the phase, scaling with team and pack size.
What it buys: a defect contained at SAT is fixed SI-side at SI cost. The same defect in UAT burns business-tester time and confidence; in live, it’s an incident. Each escape is roughly ten times dearer. Common mistake: cutting to one cycle to save a week — the unproven fixes surface in the next phase and cost the week back tenfold.
Three layers, three clocks — they run together, not instead of each other:
Common trap: consultants self-verifying their own fixes with no independent check — the Defect Manager’s evidence trail and client-side sign-off are the control. And regression cover beyond the contracted day is bought, not assumed — set it in the SOW, not in hope.
A starter-for-ten on sizing regression effort against build effort. Regression test effort isn’t a fixed ratio — it varies sharply by build artefact type. The figures below are honest practitioner estimates based on long experience with D365 implementations, not vendor-published numbers. Use as a starting point for sanity-checking your own programme’s test plan, not as benchmarks.
| Build artefact type | Regression test effort (per build day) |
|---|---|
| Pure configuration (workflows, roles, dimensions) | 0.5 – 1.0 day |
| Extensions (per-tenant or per-app) | 2.0 – 2.5 days |
| Integrations (Dual Write, Logic Apps, custom) | 2.5 – 3.0 days |
| Data migration logic | 1.5 – 2.0 days |
| Reports & Power BI | 0.5 – 1.0 day |
| Blended (typical D365 programme) | 1.5 – 2.0 days regression per build day |
Blended figure assumes a typical D365 mix: ~50% configuration, ~25% extensions, ~15% integrations, ~10% other. Heavier customisation pushes the blended ratio toward 2.5; near-out-of-the-box implementations pull it down toward 1.0.
Use as a sanity-check on your own test plan sizing — not as a benchmark.
Tick items as evidence is in. The sponsor signs the final authorisation only when all are green.
Start with the test-completion sign-offs (FAT, SAT, SIT, UAT, BAT). Each is non-negotiable.
Describe what's being tested and who's doing it. The finder maps it to the right level.