UAT sign-off: what real verification looks like, and what a rubber stamp looks like
A signed UAT document is not evidence that the system works. It is evidence that someone signed a document.
- What UAT is supposed to establish
- Six signs of a rubber stamp
- What good UAT produces
- The compression problem
- Who should sign
- Designing a UAT cycle that finds things
- Reading a defect log properly
- Regression testing after late changes
- Who owns the decision when UAT is incomplete
- Entry criteria matter as much as exit criteria
User acceptance testing carries more decision weight than any other activity on an ERP programme. It is frequently also the most compressed, because it sits at the end of a schedule that has already absorbed every upstream delay.
The result is a gate that everyone treats as authoritative and few treat as rigorous.
What UAT is supposed to establish
UAT answers one question: can the people who run this business perform their actual work in this system? Not whether the software functions as specified — that is system testing. Whether the work gets done.
The distinction matters because a system can pass every functional test and still be unusable for a process that crosses three modules and two departments.
Six signs of a rubber stamp
- Scripts written by the integrator. If the party that built the system also wrote the tests that validate it, the tests will tend to exercise what was built rather than what is needed.
- Testers who are not users. Business analysts testing on behalf of the warehouse is not user acceptance.
- Happy paths only. Real work is returns, part-shipments, credit holds, corrections and exceptions. If the scripts contain none of these, the difficult half of the business was not tested.
- Defects reclassified rather than fixed. Watch for severity downgrades clustered near the end of the cycle.
- Sign-off before defect closure. Signing conditional on outstanding fixes is common and is not sign-off.
- No traceability. If you cannot map each business process to the test that covered it, coverage is an assertion.
What good UAT produces
A UAT cycle that means something leaves behind a specific set of artefacts:
- A traceability matrix mapping business processes to executed test cases.
- Test results with dates, executor names, and pass/fail per step.
- A defect log showing severity at raise and at close, with the reason for any change.
- Explicit records of what was deferred, who approved the deferral, and what the manual workaround is.
- Sign-off by named process owners on the business side, dated after defect closure.
The compression problem
UAT gets squeezed because it is last. When design runs long and build runs long, the date does not move — the testing window absorbs it.
If your UAT window has shrunk from six weeks to two, you have not saved four weeks. You have moved the discovery of four weeks' worth of defects to a point after go-live, where each one costs considerably more to resolve and is discovered by a customer.
Who should sign
Sign-off should come from the people accountable for the process in production — the financial controller for the close, the warehouse manager for despatch, the credit manager for collections. They are the ones who will live with the consequences, which is exactly why their signature carries information.
Designing a UAT cycle that finds things
The purpose of UAT is to find problems while they are still cheap. A cycle designed to pass will pass, and will teach you nothing.
- Have the business write the scenarios, in business language, describing real work — not system steps.
- Include the awkward cases deliberately: the customer with a credit hold and a part-shipped back-order, the return that crosses a period end.
- Use migrated data, not clean test data. Real data contains the anomalies that break things.
- Have real users execute, with support available but not driving the keyboard.
- Record what people had to ask for help with. That list is your training plan.
The last point is routinely wasted. The questions users ask during UAT are the single best available predictor of where support volume will come from after go-live.
Reading a defect log properly
A defect log rewards careful reading. Several patterns are worth looking for specifically:
- Severity migration. Defects downgraded from high to medium shortly before a gate. Ask who approved each and on what basis.
- Closure without retest. Marked fixed but never re-executed. Common under time pressure and easy to check.
- Clustering. Many defects in one process area usually indicates a design misunderstanding rather than a set of coding errors.
- Reopened defects. A high reopen rate suggests fixes are being made without understanding the cause.
- The long tail. Low-severity defects that have been open since the first cycle. Individually trivial; collectively they are the day-one user experience.
Regression testing after late changes
Late configuration changes are normal. What is often missing is the regression pass that confirms the change did not break something already signed off.
If a change is made after UAT sign-off, the affected processes need re-testing and the sign-off needs re-confirming. Programmes under schedule pressure frequently skip this, which means the sign-off in the file refers to a system that no longer exists.
Worth asking directly: what configuration changes were made after UAT sign-off, and which of them were regression tested?Who owns the decision when UAT is incomplete
UAT rarely finishes cleanly. The question is who decides what an acceptable gap looks like.
That decision belongs to the business process owner, not the programme. The programme has an interest in the date; the process owner has an interest in the process working. Where that decision has migrated to programme management, sign-off has become an administrative step rather than an acceptance of risk by the person who carries it.
Entry criteria matter as much as exit criteria
Most attention goes to what must be true to finish UAT. Rather less goes to what must be true to start it, and starting UAT too early is one of the most reliable ways to waste a testing window.
Before UAT begins: system testing should be complete with results available, the environment should hold migrated data rather than sample data, interfaces should be connected, and the configuration should be frozen for the duration.
UAT begun on an unstable environment produces defects that are environment artefacts, consumes the window investigating them, and erodes user confidence in the system before anyone has seen it work properly.