User Acceptance Testing: Who Runs UAT and Where It Fits in the Testing Cycle

User acceptance testing (UAT) is the final testing phase before a system goes live, in which the actual business users — not developers or the quality assurance (QA) team — work through realistic, day-to-day scenarios to confirm the system meets their business needs. Earlier test phases prove the software works as specified; UAT proves it works for the people who will use it. On PK0-005, UAT questions hinge on two discriminators: who performs the testing and when it happens in the cycle.

What UAT is — and what it is not

UAT answers a business question, not a technical one: “Can our people do their jobs with this system?” A payroll clerk running a real pay cycle in the new system, or finance staff processing genuine sample expense reports through a new reporting tool, are performing UAT. They are validating fitness for purpose against real workflows, using realistic data, in an environment as close to production as practical.

That framing separates UAT from everything that precedes it:

• It is not about finding code defects — most of those should already be gone by the time UAT starts.
• It is not performed by the project team’s developers or professional testers. Their earlier work verifies the software against requirements; UAT validates it against the business reality those requirements were meant to capture.
• It is not optional polish. UAT sign-off is typically the formal gate for the go-live decision, and skipping it is how projects deliver systems that technically “pass” yet get rejected by the departments that must live with them.

The distinction between verification and validation is worth internalizing: verification asks “did we build the system right?” (developer and QA testing), while validation asks “did we build the right system?” (UAT).

Where UAT sits in the testing cycle

PK0-005 expects you to know the standard progression of test phases and to place a scenario in the right one:

Phase	Who performs it	What it checks
Unit testing	Developers	Individual components or functions in isolation
Integration testing	Developers / QA	That modules work correctly together (interfaces, data hand-offs)
System testing	QA team	The complete assembled system against the full requirements
Regression testing	QA team	That new changes haven’t broken previously working functionality
User acceptance testing	Business end users	That the system supports real business workflows and needs
Smoke testing	QA / operations	A quick pass to confirm the build is stable enough to test or deploy at all

The core sequence is unit → integration → system → UAT → go-live. Regression testing recurs after any change rather than occupying one fixed slot, and a smoke test is a fast sanity check rather than a full phase. UAT is deliberately last among the functional phases: there is no point asking business users to validate workflows on a build that still fails system testing.

Running UAT well

A project manager doesn’t execute UAT, but is accountable for making it succeed:

• Define acceptance criteria up front. UAT scenarios should trace back to documented requirements and measurable acceptance criteria agreed during planning — not invented on the fly during the test window. Ambiguous criteria produce ambiguous sign-offs.
• Recruit representative testers. Pull participants from each affected business role — the stakeholder register tells you who those roles are — including the skeptics. A UAT group of only enthusiastic early adopters validates nothing.
• Script realistic scenarios, allow exploration. Structured test scripts guarantee coverage of critical workflows; unscripted time lets users stumble into the edge cases scripts miss.
• Use production-like data and environment. Testing an expense system with fabricated round-number reports hides the messy realities (split approvals, foreign currencies, rejected receipts) that real data exposes. If genuine production data is used, the usual data-handling controls still apply — masked or minimized data wherever possible.
• Manage defects by severity. Not every UAT finding blocks go-live. Critical defects must be fixed and retested; cosmetic ones can be logged for a post-launch release. The triage rules should be agreed before testing starts.
• Get formal sign-off. UAT concludes with documented acceptance from the business — the gate that authorizes the transition to deployment and closing activities. That sign-off is a key project artifact, referenced later if disputes arise about what was accepted.

For where this gate sits within the broader phase structure of a project, see the PK0-005 study guide.

How the PK0-005 exam tests this

• A “name that phase” scenario: employees from a business department (finance, HR, operations) — explicitly not developers or testers — process realistic sample transactions in a new system before launch, and you must identify UAT against distractors like system, integration, or regression testing. The tester’s identity is the giveaway.
• A sequencing question: which testing phase occurs immediately before go-live, or in what order the phases run — UAT comes after system testing and before deployment.
• A discrimination item contrasting regression testing (re-checking existing functionality after a change) with UAT (business validation before release); scenarios that mention “after applying a patch, verify nothing else broke” are regression, not UAT.
• A governance angle: what artifact or event authorizes go-live — formal UAT sign-off against the documented acceptance criteria.

Both discriminators — who tests and when — come up constantly in Project+ practice questions, and they’re quick points once the pattern registers.

Quick reference

• UAT = business end users validating that the system meets real business needs; developers and QA verify, users accept.
• Position in the cycle: unit → integration → system → UAT → go-live.
• Verification = “built it right” (technical testing); validation = “built the right thing” (UAT).
• Regression testing re-checks existing functionality after changes; a smoke test is a quick build-stability check — neither is UAT.
• UAT needs predefined acceptance criteria, representative users, realistic data, and a production-like environment.
• Findings are triaged by severity; only go-live-blocking defects must be fixed within the UAT window.
• Formal UAT sign-off is the acceptance gate that authorizes deployment.