UAT is not the integrator’s final report: it is the sponsor’s decision. It answers a question nobody can settle for them: can the business work with what was delivered, on its real cases, with its own access rights and data? The integrator’s tests prove the tool does what the specification describes. UAT says whether that is enough to launch. So the scenarios come from the business, the criteria and severity scale are set before the first test, and the sponsor signs what they saw pass, not what they are told.
Take a discount request above the authorised threshold. The integrator shows the approval rule fires, the status changes and the notification goes out: the test is green, and rightly so. UAT asks other questions. Can a sales rep, logged in with their own profile rather than an admin account, submit the request from the opportunity? Does the deputy see it when the manager is away? Can the finance controller find the reason for the discount in their month-end report? Any of these can fail while every one of the integrator’s tests passes.
What is UAT for, if the integrator has already tested?
The two test campaigns do not answer the same question. The integrator checks its delivery: each rule, field and automation does what the specification asks, the integrations exchange the right messages, fixes do not break what worked. That is necessary, and it is the integrator’s job. But those tests start from the specification. If it missed a case, the tests miss it too, and they pass.
UAT starts from the other end: the real work. It does not ask whether the rule works, but whether the team can get through its day. It tests the hand-offs from one step to the next, the exceptions, access rights as each user group sees them, the reports a decision depends on. It is the only moment when the business tests the tool against its own work before that work depends on it.
There is a simpler reason too. The integrator is paid to deliver. Its test report is a useful document, often carefully made, but it comes from an interested party. Asking the integrator to pronounce acceptance means letting it mark its own homework. The sponsor reads that report as a condition for entering UAT.
Who writes and who runs the scenarios?
The business, in both cases. Each team’s key users write the scenarios from their processes: one scenario per complete journey, from first contact to invoice, from case opened to case closed, with the awkward cases (the duplicate customer, the order cancelled after approval, the absent manager, the record migrated from the old system). Each scenario carries its expected result, written before it runs, and the name of the person who runs it.
They run them themselves, with the real users’ profiles and permission sets, in a sandbox loaded with representative data. A scenario run with an admin account proves nothing about access rights. A scenario run on a handful of test records proves nothing about the quality of migrated data: UAT builds on the rehearsals of the data migration.
The integrator has a different role. It prepares the environment, creates the accounts, loads the data, unblocks testers when the tool stops them, analyses defects and delivers fixes. It reviews the scenarios to flag what falls outside the contractual scope. It neither writes nor runs them. The common trap is a well-meant offer: “the test cases already exist, your teams only need to rerun them”. Those cases were written by the people who built the tool. They pass by construction, and the missed case turns up in production.
This assumes key users who are available and trained before UAT starts. A tester seeing the screen for the first time cannot tell a defect from a handling error. So the training plan follows the UAT calendar, and testers’ time is booked with their managers at scoping.
What must be settled before the first test?
The criteria and the severity scale are signed before the first defect exists.
Entry criteria first: environment frozen, data loaded, accounts created with the right access, the integrator’s test report delivered, testers trained. If one is missing, UAT does not start. UAT launched on an environment that is still changing measures only yesterday’s deliveries.
Then the severity scale, with a definition per level and an example drawn from the business’s processes. Blocking: the process stops and no acceptable workaround exists. Major: a workaround exists, but it costs time, creates a risk or relies on a single person. Minor: an annoyance with no effect on the outcome. Cosmetic: a label, a layout. The business rates severity against this scale, the integrator gives its technical opinion, and a disagreement goes up to the sponsor instead of being negotiated ticket by ticket.
Finally the exit criteria: every critical scenario passed, no blocking defect open, each open major defect with a written workaround, an owner and a date, and the list of deferred minor defects accepted by the business.
Why before? Because once testing starts, every severity becomes a negotiation. When a payment or the launch date depends on the number of blocking defects, every blocking defect has a reason to become major. A scale signed while nothing is at stake settles these debates before they start. It must say the same thing as the contract: UAT, its content and its effects are settled before choosing the integrator, and a scale that contradicts the contract does not survive the first disagreement.
What does the sponsor sign, and what do they never sign on trust?
The sponsor signs an acceptance certificate, and that document states specific things: the scope tested and the version delivered, the scenarios run and their results, the open defects with their severity, owner and date, the reservations, the decision. The sponsor accepts, accepts with reservations or rejects. Accepting with reservations is a complete decision: each reservation has an owner, a date, and a written consequence if the date is missed.
They sign what they saw: they attend the run of the critical scenarios, the ones without which the company would not launch, and read the results scenario by scenario rather than a pass rate. A high rate can hide the one failure that matters.
They never sign on someone else’s word. “All tests are green”, when those are the integrator’s tests. “The remaining defects are minor”, without the list or the business’s view. “It will be fixed after launch”, without an owner or a date. A scope cut along the way that the certificate does not record. A feature announced for the next phase carries no weight in the decision: the sponsor signs what runs in the sandbox.
Before signing, they ask in writing what the signature triggers under the contract: a payment milestone, the start of a warranty, the end of the integrator’s presence on the project. A signature that releases a payment and starts the warranty clock is not given to keep to a schedule.
What do you do when UAT does not pass?
Rejecting is one of the planned outcomes: UAT is doing its job. What comes next is decided in writing: postpone the launch to a date tied to fixing the blocking defects, not to the integrator’s calendar; narrow the launch scope by removing the failing process, with its own UAT schedule; or accept with reservations, if the only remaining gaps are major defects with a workaround.
What the sponsor rules out: launching anyway and counting on the warranty to absorb the blocking defects. A fix in production is made under pressure from users, without the sandbox as a safety net, and the first weeks decide what the teams will think of the tool.
A new UAT cycle reruns the scenarios touched by the fixes, then the critical scenarios in full. A fix that repairs one step sometimes breaks another, and only an end-to-end scenario shows it.