Acceptance is a skill the client has to learn
On many projects, user acceptance testing is new to the client. The people asked to run it usually have a day job, no test scripts and no clear picture of what done looks like. If we hand over a build with the words please test, we should not be surprised by what comes back.
So I run the first UAT sessions together with the client, to help them. We go through the scenarios side by side, so that they can see how a test is run, how a finding is recorded and how to tell a defect from a wish. It takes time, and in my experience it is the cheapest way to get a useful result.
Nobody should discover the definition of done during UAT.
What I try to make clear before the first session
- Acceptance criteria. Agreed in writing before testing starts, in business language, and traceable to the requirements.
- Scenarios built on real work. A scenario follows a business situation from start to finish, not a list of screens.
- Simple defect categories. Blocks go-live, must be fixed soon, can wait. A new wish is not a defect: it goes through the change process.
- One list of findings. One owner and one status per item, reviewed together while UAT is running.
- An exit rule. Which open issues still allow sign-off, and which do not.
None of this needs heavy tooling. A shared spreadsheet or the project tracker is enough, as long as everyone uses the same one. What matters is that the client can see, at any moment, what has been tested, what has been found and what is left to do.
Why a fixed price makes this sharper
In my projects the billing plan is 30% in advance, 40% at UAT and 30% at production go-live. That is deliberate. Acceptance is where the client confirms that the product does what was agreed, and it is also where a large part of the money is released.
If nobody has agreed what accepted means, the milestone turns into a negotiation at the worst possible moment, for both sides. Agreeing the criteria early, and showing the client how to apply them, takes most of the heat out of that moment.
What the first sessions are really for
Teaching the method is only half of it. The first sessions are also where trust is built or lost. A client who has been shown how to test, and who sees findings logged openly and sorted fairly, tends to trust the outcome. A client left alone with a build tends to find that trust slowly and at a higher price.
The aim is that, by the second or third round, the client's own testers run the sessions and I sit at the side. At that point the knowledge stays with the client, which is exactly what a handover should leave behind.
Quality on a project is not only what the team builds. It is also what the client is able to recognise as right, and that is something we can build together.