Eight test levels, with explicit role distinctions.

The eight levels

Source of truth

Each level has a different purpose, a different audience, and different exit criteria. The table below is the source of truth — the rest of the page elaborates on the parts most likely to drift.

Sequence

How it runs

Unit → FAT → Mini-BAT → SAT → SIT → Pre-UAT → UAT → BAT, with NFT in parallel with BAT and validated against the same functionality.

Pre-UAT sits in the sequence even though it isn't a test level in its own right — it's a preparation phase.

Pre-UAT

Preparation, not a level

Pre-UAT is a Client preparation phase that sits between SIT and UAT. It is not a test level — it is the work that makes UAT possible. Skipping it is one of the top reasons UAT itself fails or runs late: day one of UAT becomes script-fixing day, and a third of the planned UAT window is lost before testing begins.

In short: the Client Test Manager and Process Owners author UAT scripts against L3 / L4 process maps, the project team rehearses them on the UAT environment, script defects are fixed, and the core team familiarises itself with the system as the "trainers of trainers" for UAT users.

What makes UAT different

UAT is by the business, signed off per workstream

The test level most likely to drift if not pinned down clearly.

SAT vs NFT

A common drift is calling NFT "SAT" or rolling SAT into SIT. They serve different purposes: SAT proves the system works end-to-end functionally; NFT proves it performs and is secure. Both are needed. Neither substitutes for the other.

UAT vs BAT

UAT is scripted, traceable, formal — it is the audit trail. BAT is scenario-based, unscripted, realistic — it tests business readiness. A system can pass UAT (every script passes) and still fail BAT (the day-in-the-life feel is wrong). Both are needed.

Who controls UAT, who executes, who supports

The Client Test Manager controls UAT — owns the strategy, runs the testing, manages the defect process. Users execute the scripts — actual business representatives who will use the system day-to-day. Process Owners contribute and support — co-author scripts at Pre-UAT, validate coverage, support users during execution, sign off acceptance per workstream. They do not run the testing programme and they do not execute the scripts themselves.

If Process Owners execute UAT scripts, the resulting evidence trail does not reflect real user experience. It produces paper acceptance with no operational signal — which is exactly why some programmes pass UAT and still fail at go-live.

UAT scope

Three categories

A complete UAT plan covers all three categories. Skipping any one of them leaves a known class of defect untested.

• End-to-End (E2E) tests. Multi-department processes run end-to-end. For example, an order from a supplier through shipping, receiving, invoicing and paying, including edge cases like partial shipment, multi-currency, returns.
• Isolated tests. Single-workstream tests that don't depend on other teams. For example, changing a VAT rate on a product, or checking field-level access for a role.
• Day-in-the-Life-Of and Week-in-the-Life-Of (DILO / WILO). Simulating a real business day or week to validate the solution under realistic load and sequencing. Catches issues scripts miss because real days have multiple users doing overlapping things.

Beyond the three scope categories, UAT also covers Role Testing (system profiles match real organisational roles) and Business Readiness (cutover and go-live test, typically one to two weeks before go-live, bridging UAT and BAT).

Cycles, data, regression, automation

The mechanics underneath the eight levels

Four operational disciplines sit underneath the eight levels. The principles are short; the templates are in the toolkit.

Multi-cycle for SAT and SIT

SAT and SIT run as Sanity → Cycle 1 → Cycle 2 → Cycle 3. Single-cycle is a common mistake — defects found in cycle one have no chance to be retested in the same phase.

Test data is the silent partner

A perfect script run on the wrong data produces useless evidence. Synthetic is fine for Unit and FAT; SAT needs structurally complete synthetic; SIT and UAT need realistic, ideally mock-migrated; BAT needs a cutover-like data state; NFT needs production-volume synthetic. The common trap is running UAT on a stale data set because the mock load slipped — users hit data they don't recognise and the programme looks broken when it's actually a data freshness problem.

Regression across the whole pipeline

Regression isn't a phase — it runs across the pipeline. FAT per sprint, SAT establishes the pack, SIT re-runs it with integrated third parties, UAT regression runs nightly to catch regression introduced by defect fixes, post-go-live regression runs against every patch and config change. Risk-driven, not ceremonial.

Automation: the twenty per cent re-run eighty per cent of the time

Automation lands primarily at Unit, FAT and the SAT regression pack, plus NFT (automation-by-default). UAT and BAT are user-driven and stay manual. The biggest mistake is treating automation as a Build-phase activity that ends at go-live; the regression pack is a permanent capability that runs through every subsequent release. Demand a pre-existing automation framework from the SI, dedicated automation engineers in the test team, a regression pack handover plan in the SOW, and realistic expectations.

Test Strategy template, Test Plan, Defect Management Plan, cycle worksheets and data-strategy sheets are in the Supporting Documents. The Command Centre walks the operational mechanics interactively — cycles, data tables by level, automation tooling by platform.

Recurring bad habits

To correct on sight

Nine things that go wrong across ERP testing, again and again. Each one feels reasonable when the decision is made; each one costs more than was saved.

• Process Owners executing UAT scripts. Produces paper acceptance with no operational signal. The Client Test Manager controls UAT; users execute; Process Owners contribute, support and sign off acceptance per workstream.
• Conflating SAT with NFT, or rolling SAT into SIT. They are different things — functional vs non-functional, full-system vs integration. Keep them named separately.
• Skipping Pre-UAT. Day one of UAT becomes script-fixing day. Cost: three to five days of UAT and the morale of the user group.
• Compressing testing because build overran. Every day cut from testing increases the probability of go-live defects. The Programme Manager has to hold the line.
• "Test Lead" without "SI" or "Client" qualification. Ambiguous — there are two: SI Test Lead (owns SAT, supports SIT) and Client Test Manager (owns SIT, coordinates UAT and BAT). Mixed sign-off chains follow from mixed naming.
• UAT scripts written by the SI rather than the business. SI-written scripts test what the SI built, not what the business actually does. Scripts must be written by the business at Pre-UAT.
• Single-cycle SAT or SIT. Defects found in cycle one don't get retested in the same phase. Standard is three cycles plus a sanity test.
• Treating NFT as a footnote because it runs in parallel with BAT. Performance, security, disaster recovery and batch failures are some of the worst go-live failures. NFT is a level in its own right.
• Delegating sign-off when the named role is unavailable. Sign-off chains are non-transferable. "Signed on behalf of" produces contested exits and ugly hypercare conversations. Wait for the named role.

Going live

The testing exit gate

Go-live readiness against testing requires evidence at five levels: all test-level exit criteria met (SAT, SIT, UAT, BAT, NFT); zero P1 defects open, zero P2 open or formally accepted with documented workaround and post-go-live fix plan; BAT signed off by Benefit Owners; data migration validated through Dry Run 2 at full volume; NFT exit certificate issued by IT Operations and Solution Architect.

The decision to proceed with cutover sits with the Executive Sponsor at the cutover Go/No-Go, end of Cutover Planning (S15) / start of Deployment & Go-Live (S16). See the Gates & business case page for the full gate scheme.

On cloud deployments the platform vendor sets a parallel set of exit criteria. Microsoft (LCS / FastTrack), SAP, Oracle and Workday will not provision production until their own thresholds are met. The Client Test Manager and SI Test Lead carry both gates.

Sign-off is non-transferable. If the named role is unavailable on the day, the test exit waits — it does not delegate down. "Signed on behalf of" is a recurring source of contested gates and unhappy hypercare conversations. The cost of waiting a day for the named role is materially smaller than the cost of the dispute that follows when an exit is later challenged.