User Acceptance Testing (UAT): A Practical Guide

User acceptance testing (UAT) is the final testing stage, where the client or real users check that the software meets their needs before it goes live or is formally handed over. Your team's QA asks "does it work as specified?" UAT asks "is this what we actually wanted?"

Those are different questions, which is why UAT catches problems that passed every internal test.

Who runs UAT

UAT belongs to the client side. Your team prepares and supports it, but the people testing should be the ones who will use the software or who are accountable for it.

• Business owners confirm it meets the agreed scope.
• End users check it fits how they actually work.
• Your team answers questions, fixes issues and records the outcome.

If your own testers run UAT on the client's behalf, it is not really acceptance testing. It is more QA.

Prepare before you hand over

Most UAT pain comes from unclear expectations. Before inviting the client in:

1. Finish internal QA first. Clients should not be finding obvious bugs. See QA sign-off for that gate.
2. Agree what is being accepted. List the tickets or features in scope for this round.
3. Write simple scenarios. "Create an order, cancel it, check the refund email" is better than "test orders".
4. Set a window. UAT without a deadline tends to drift for weeks.
5. Explain how to report issues. One channel, with screenshots, not a mix of email, calls and chat.

Need proof your work was tested? See how Flow records test runs and sign-off as evidence. Get started with Flow →

Handling UAT feedback

Feedback will arrive as a mix of real defects, change requests and preferences. Sort it quickly:

• Defect — it does not match what was agreed. Fix it.
• Change request — it works as agreed, but the client wants something different. Estimate and schedule it.
• Preference — note it and discuss. Not every comment is a ticket.

Separating these protects your timeline and keeps scope honest. Our guide to managing client feedback covers this in more detail.

Closing UAT with a clear decision

UAT should end with a recorded decision, not a vague "looks good" in an email thread. The client either accepts the work, or rejects it with reasons you can act on.

Teams on Jira often manage UAT with a dedicated issue type or board, and some add TestRail or a marketplace test app for structured test cases. That can work well, though a client-facing portal in the Atlassian world usually means Jira Service Management, a separate product. The key, whatever the tooling, is that the client's decision is captured somewhere you can find it later.

How Flow helps

Flow gives clients a proper place to take part in UAT.

• Client board. Tickets are internal by default; you choose which ones the client sees for this round of testing.
• Client-raised tickets. Clients can raise issues with screenshots and comment on work, all in one channel.
• Formal sign-off. Clients approve or reject delivered work, and you get an auditable sign-off report.
• Sealed records. Livex Flow can produce a Client Sign-off Record (CSR) or a Rejection (REJ) document, sealed and verifiable, so the outcome cannot quietly change. More in our guide to client sign-off.