User Acceptance Testing: How a Client Should Test Software Before Signing It Off

Your development team says the software is finished and asks you to test it and sign it off. Nobody on the business side has been told what "testing" means in practice, so a few people click around for an afternoon, nothing obvious breaks, and the sign-off email goes out.

The problems show up three weeks after launch, when a real order with a discount and a split delivery cannot be invoiced. User acceptance testing, usually shortened to UAT, exists to catch that before you accept the work. It is the one part of custom software development that the client has to do, because only the client knows how the business actually runs.

What UAT Is, and Who Should Do It

User acceptance testing is the check, carried out by the people who will use the software, that it supports their real work well enough to go live. It answers a different question from the developers' own testing. Developers and QA testers check that the software does what the specification says, usually against an agreed standard of completeness. In Scrum, for example, the Scrum Guide says work that does not meet the team's Definition of Done cannot be released. UAT asks something the developers cannot fully answer: is what was specified actually what the business needs?

A feature can pass every developer test and still fail UAT, because the specification may have missed a step or misunderstood a rule.

That is why the testers should be the people who do the job every day: the accounts clerk, the warehouse supervisor, the customer service lead. Managers alone are a poor substitute, because they know the policy but not the workarounds. Include at least one person from each role that has different permissions in the system.

Write Test Scenarios From Real Work

Do not test from the feature list. Test from the working day. Ask each tester to write down the tasks they completed last week and last month end, then turn each into a scenario with a starting point, an action and an expected result. The Given-When-Then format, which the Agile Alliance describes as a template for writing acceptance tests, works well for non-technical staff: given some starting context, when an action is carried out, then a specific observable result should follow.

An illustrative example: given a customer with an unpaid invoice older than 60 days, when a sales rep tries to create a new order, then the system holds the order and notifies the credit controller.

Leave some unscripted time as well. The UK government's Service Manual describes exploratory testing as exploring a system the way a user would, without a script, and notes that it finds subtle defects that scripted checks miss.

Test with realistic data

Tidy sample data hides problems. Real data has customers with three addresses, names containing apostrophes and products with no weight recorded. Ask for a test environment loaded with a realistic volume of records, ideally a copy of your migrated data, and check the migration itself by comparing a sample of records and totals against the old system.

If that data includes personal information, treat the test environment with the same care as the live one. The UK Information Commissioner's Office states that pseudonymised data is still personal data, so masking names does not remove your obligations. US requirements vary by state and sector. This is not legal advice; confirm with whoever handles privacy for your company.

How to Report a Bug So It Gets Fixed Quickly

The speed of a fix depends heavily on the quality of the report. Mozilla's long-standing bug writing guidelines call the steps to reproduce the most important part of any report, and recommend one report per issue. A useful report contains:

• A one-line summary of the problem, not your proposed solution.
• The exact steps you took, numbered, including the account you were logged in as and the record you used.
• What you expected to happen and what actually happened.
• A screenshot or short screen recording, plus the browser or device and the time it happened.

Put every report in one shared tracker, not in emails, chats and calls. Separate genuine defects from change requests as you go. "It does not do what we agreed" is a bug. "We agreed this, but now I see it I want something different" is a change, and it is normally handled, and paid for, separately.

Severity Levels and What Should Block Launch

Not every bug should stop a launch, and a list of two hundred unranked issues helps nobody. Agree a severity scale with your developer before testing begins. The names vary between teams, but a typical scale looks like this:

• Critical: a core process cannot be completed, data is lost or corrupted, or there is a security or privacy exposure.
• High: a key function is wrong and the only workaround is slow or risky.
• Medium: something is wrong but a reasonable workaround exists.
• Low: cosmetic or wording issues that do not affect the work.

A sensible launch rule is no open critical or high issues, with medium and low issues listed, agreed and scheduled for fixing after go-live. Severity describes the impact on the business, so the client should set it.

Acceptance Criteria and Sign-Off in the Contract

Sign-off is usually a contractual event, not a courtesy. It commonly triggers the final payment, starts the warranty or support period, and moves later fixes into paid maintenance. Read the acceptance clause before you start. Check how many days you have to test, what counts as a valid reason to reject, how many rounds of fixing and retesting are included, and whether silence counts as acceptance once the period ends. Many contracts contain such a "deemed acceptance" term.

The strongest position is to have acceptance criteria written down before development: the scenarios that must pass, the severity rule above, and any performance or compatibility expectations. Our guide to outsourcing software development from the US and UK covers the wider contract. Have a lawyer review terms that matter to you.

How Much Time to Set Aside

There is no standard duration, and the common error is to treat UAT as a few days at the end. The time needed depends on the number of scenarios, the number of roles, how many integrations and data migrations are involved, and above all how much time your testers can give alongside their normal jobs. Plan for at least two passes: a first run through every scenario, then a retest of the fixes plus a repeat of the core scenarios to confirm nothing else broke.

Block the time out in people's calendars and reduce their other workload for the period.

Common Mistakes

Testing only the happy path. The standard order with a standard customer nearly always works. Test the refund, the cancelled order, the duplicate entry, the user without permission, the form abandoned halfway, and the busiest hour of the month. UK government guidance on quality assurance makes the same point: you do not know how good a product is until it has been tried under both normal and unusual conditions.

Testing too late. If the first time real users see the software is two weeks before launch, any significant finding forces a choice between delay and going live with known faults. Ask for working software at regular intervals and have users test each piece as it is delivered.

No one owning the decision. When five people test and nobody is authorized to say yes or no, sign-off drifts or happens by default. Name one person who settles disputes over severity and makes the final go or no-go call.

What to Do Next

If your project is under way, do three things this week. Read the acceptance clause in your contract. Name the decision owner and the testers. Ask each tester for ten real tasks from their own work and turn them into scenarios with expected results. Then agree the severity scale and the tracker with your development team, and ask when a test environment with realistic data will be ready.

Conclusion

UAT is the client's last practical chance to confirm that the software fits the business before accepting it. It works when the people who do the work test real scenarios with realistic data, report problems in a form developers can act on, and judge readiness against criteria agreed in advance.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you are planning a project and want acceptance criteria and a testing window built into the plan from the start, you can contact our team to talk it through.