User acceptance testing checklist: what to verify before you sign off delivered software

Before you sign off user acceptance testing, check four things: every item in the contract's scope has been tested with real business scenarios, the remaining defects are listed on the sign-off with deadlines, the deliverables (code, documentation, access) have actually been handed over, and the go-live has a rollback plan. Signing is not a formality. In most contracts, it releases the final payment, starts the warranty period, and makes it harder to claim anything that was visible at the time.

Most UAT checklists online are written for QA teams running the tests. This one is written for the other side of the table: the business owner or project sponsor who has commissioned software from an agency or studio and has to put a signature at the bottom of the acceptance form. It explains what UAT is, how to build useful test scripts, then runs through the checklist to complete before you sign.

UAT in one paragraph

User acceptance testing is the client verifying that delivered software does what was agreed. The supplier tests its own work continuously; UAT is the moment when you check, on an environment close to production, with your own cases. Contracts call the outcome an acceptance certificate, a sign-off or an acceptance notice; the effect is the same.

It matters for one simple reason: it is the last point at which you have real leverage. Before sign-off, a defect is a non-conformity the supplier must fix. After it, the same defect often becomes a maintenance request, or even a paid change.

The three levels of acceptance

Public procurement frameworks often name and time these stages precisely. In a private contract, nothing is imposed: the contract defines the stages, the deadlines and the effect of each decision. Read it before you start, not when a disagreement arises. Our guide to software development contract clauses covers the acceptance clause alongside the others.

Test scripts: what they must contain

The test scripts (sometimes called the UAT plan or test book) are the list of checks to run. They follow directly from the requirements or the validated scope: every stated need should have at least one test case. If you started from a software requirements document, the mapping is line by line.

A test case, in practice

A good test case can be followed by someone who does not know the software. It includes:

• an identifier and the function under test;
• preconditions: which user, with which permissions, which data present;
• the steps, in order;
• the expected result, phrased so it can be checked;
• the actual result, the status (pass, fail) and the severity if it fails.

An example for a quoting application:

The scenarios people forget

The happy path is always written. The other cases are the ones that cause trouble in production:

• business exceptions: the credit note, the cancellation, the customer with no VAT number, the partial order, the product removed from the catalogue;
• permissions: what a role must not be able to see or do;
• volumes: the list with ten thousand rows, the full-year export, the import of a malformed file;
• outputs: PDFs, emails sent, exports to accounting;
• integrations: what goes out to other systems and what comes back;
• mobile use: the screen used standing in a warehouse, on a weak network.

Who writes them

The client is best placed to write the business scenarios: it knows its awkward cases. The supplier helps structure them and adds its technical tests. Scripts written only by the supplier test the supplier's understanding of the need, which is not the same thing as the need.

Classifying defects

Not all defects are equal. A severity grid agreed before testing starts saves you negotiating every ticket:

The contract or test plan must say who sets the severity, and how a disagreement is settled. Without that rule, every major defect becomes "minor" in the supplier's report.

The checklist before you sign off

These are the points to verify yourself, or to have verified by whoever runs the project on your side. Each "no" is either a reservation to write down or a reason to postpone the signature.

Scope

• Every function in the contract has at least one test case, and it has been run.
• Test cases have been run by real users, not only by the supplier.
• The business exceptions listed above have been tested.
• Differences between what was planned and what was delivered are written down, including those agreed during the project.

Data and security

• Testing used realistic data. If it is real personal data, it has been anonymised or its use properly framed, as the GDPR requires; our GDPR checklist for business applications covers the details.
• Every user role has been tested, including what it must not see.
• Data migrated from the old tool has been checked on a sample, by the people who know that data.
• Basic security is covered: passwords, permissions, logging of sensitive actions.

Operations

• A backup has been restored at least once, not merely scheduled.
• Monitoring is in place: a named person is alerted when the application goes down.
• Go-live has a date, an owner, and a rollback plan if it fails.
• Performance has been observed with a volume close to real use.

Deliverables

• The source code is stored where the contract says, and you know how to access it.
• Hosting, the domain name and third-party service accounts are in your name or accessible to you.
• Documentation exists: installation, deployment, business rules, user guide.
• Users have been trained, or training is scheduled.
• Rights over the code and deliverables match the contract, with rights defined case by case in the contract.

The sign-off document itself

• It identifies the exact version tested (number, delivery date).
• Each reservation is precise, linked to a test case, with a correction deadline.
• It states what happens if a reservation is not cleared in time.
• You know what the signature triggers: payment, start and length of the warranty, start of the maintenance contract.
• The person signing has the authority to do so in your company.

Three possible outcomes

Acceptance without reservations. The software conforms. That is the outcome to aim for, provided the checklist was completed honestly.

Conditional acceptance. The software can go live, but non-blocking defects remain to be fixed. It is the most common outcome, and it is not a failure. What matters is the precision of the reservations: "a few display bugs" protects nobody; "case QUO-07: the discount is not carried over to the invoice, fix within ten working days" is enforceable.

Rejection. Blocking defects remain, or the scope is not covered. The rejection must be written, reasoned and linked to the failed test cases. The supplier fixes and delivers a new version, which goes back through testing, at least on the cases concerned plus a sample of cases already passed, to check that the fix broke nothing else.

The traps that cost money

Deemed acceptance. Many contracts state that silence beyond a deadline, or putting the software into production, counts as acceptance. Read that clause before you start, note the deadline, and never go live with software you have not formally accepted without saying so in writing.

Testing without the users. The director or project manager approves the screens in a meeting, and the teams discover the tool on launch day. Defects found afterwards are the most expensive to get fixed.

Testers who were never released. Testing happens "on top of" normal work, so it is half done. Block time in calendars, as you would for training.

Change requests disguised as defects. A new need discovered during testing is not a non-conformity. Mixing it with defects creates a pointless conflict with the supplier. Log it separately: it will feed the next phase.

Testing everything at the end. On a project lasting several months, a single acceptance phase at the end concentrates every risk. Accepting each increment as it is delivered surfaces misunderstandings while they are still cheap, which is one of the principles of an agile fixed-price contract.

How long to plan

No standard duration fits every project. The honest calculation is simple: the number of test cases, multiplied by the time each takes, plus writing defect reports, plus at least one second pass after fixes. Then factor in the real availability of your testers, which is almost always the limiting factor. For operational acceptance, the duration is the one set by the contract; it should cover at least one full business cycle, such as a month-end close if the software touches it.

After sign-off

Acceptance does not end the software's life. The first weeks in production surface cases nobody imagined. The contract must say how they are handled: fixed under warranty when they are non-conformities, through maintenance or as enhancements otherwise. Our article on business application maintenance describes that period.

Acceptance starts before development

The best acceptance testing is the one where nothing comes as a surprise, because the client saw the software before it was built. A scope made visible, screen by screen, becomes the shared reference: the test scripts follow from it, and disputes about "what was agreed" almost disappear.

That is the role of the free visual prototype LPR Studio presents by video call within 5 working days, before any commitment. On a fixed-price project, it then serves as the basis for the scope, and later for acceptance.