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. See below.

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.

What happens during Pre-UAT:

• The Client Test Manager and Process Owners author UAT scripts based on the actual business processes (typically against L3 or L4 process maps).
• The Client project team rehearses every script on the UAT environment to validate that the scripts work and the system is ready.
• Script defects are fixed before users arrive.
• The core project team familiarises themselves with the scripts so they can act as trainers-of-trainers for UAT users.

Skipping Pre-UAT is one of the top reasons UAT itself fails or runs late. If the scripts haven't been rehearsed, day one of UAT becomes script-fixing day rather than testing day. The two days spent not testing on day one cost a week of UAT later.

Distinctions

Four lines that matter

Four distinctions where most testing structures drift, and the line Keystone holds.

FAT vs UAT

FAT is field-level and configuration-level. It tests that individual user stories or configurations work as designed — for example, "the system allows creation of a case record with fields X, Y, Z; confirm field types and validation." Executed by the SI Tester, accepted by the Process Owner at sprint review.

UAT is process-level and business-flow. It tests end-to-end business journeys — for example, "a Client advisor opens a case, captures contact details, progresses through the case journey to closure." Executed by users; signed off by the Client Test Manager and Process Owners.

If a tester is checking field validation, that's FAT. If a tester is walking through "I'm a stock controller; show me my Tuesday morning workflow," that's UAT.

SAT vs NFT

SAT is full-system functional testing — the integrated solution against the Solution Design Document. It runs after build and before SIT.

NFT is non-functional testing — performance, load, volume, security, penetration, disaster recovery. It runs in parallel with BAT, against the same functionality.

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. Can the team actually run their day on this system? Are the multi-user, overlapping flows manageable in practice? Are there hidden friction points that scripts didn't catch?

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. They are actual business representatives who will use the system day-to-day, working through the scripted business journeys hands-on.

Process Owners contribute and support. They co-author scripts at Pre-UAT. They validate coverage. They support users during execution. They 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 that 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).

Recurring bad habits

To correct on sight

Eight 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. Correct on sight when you see them in your own programme.

• Process Owners executing UAT scripts. Produces paper acceptance with no operational signal. The Client Test Manager controls UAT; users execute the scripts; Process Owners contribute and support, signing 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. The discipline is to keep them named separately.
• Skipping Pre-UAT. Day one of UAT becomes script-fixing day. The cost is at least 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, and the Steering Committee has to support that.
• "Test Lead" without "SI" or "Client" qualification. "Test Lead" is ambiguous — there are two: SI Test Lead (owns SAT and 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 UAT scripts test what the SI built, not what the business actually does. UAT scripts must be written by the business at Pre-UAT.
• Single-cycle SAT or SIT. Defects found in cycle one don't get a chance to be retested in the same phase. The standard is three cycles: cycle 1 (full execution), cycle 2 (medium-risk areas plus retest), cycle 3 (full retest of all open defects plus any new ones).
• 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 and deserves the same governance attention as UAT and BAT.

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 defects open, or formally accepted with a documented workaround and a 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.

Vendor prerequisites on cloud deployments

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 — regression test pass rate, NFT certificate, defect thresholds. These align with the Client's UAT and BAT exit criteria but are independent of them. A common mistake is the programme passing its own test exit and then failing the vendor's deployment readiness check, slipping production by weeks. The Client Test Manager and SI Test Lead carry both gates.