In this guide 6 sections
Write pass or fail criteria first. Then let the people who will use the software test it with their own data in a copy of the live setup, logging each defect they find. Retest every single fix. Sign the acceptance sheet only when every criterion in the contract has a recorded result from a named tester, dated and kept.
Write the acceptance criteria before anyone logs in
Open the signed scope document and the vendor’s proposal, then pull out every promised behaviour and rewrite it as a test with one expected result. “Supports invoicing” is a promise. “Raise an invoice for a customer with two tax rates, then download the PDF and compare the tax lines with the contract” is a test. Keep the scope document, change requests, email approvals and the vendor’s demo notes beside you, since disputes later turn on what was agreed in writing and when.
Give each criterion a number, an owner and a priority, and mark the ones that block go-live, so the team can see what must pass before launch. Cut the list to fit.
Agree the final list with the vendor by email before testing begins, because changing criteria after the first login is how disputes begin.
- Criterion number and the scope clause it comes from
- Steps the tester follows, in plain words
- Expected result, including any figure or document produced
- Priority: blocks go-live, fix soon, or cosmetic
Choose testers who do the job today
Vendor testers know the happy path. You need the dispatcher, the accounts clerk and the branch manager, because they know which shortcuts and odd cases fill a normal Tuesday. A good group mixes a heavy user who knows every shortcut with an occasional user who gets lost easily, since both kinds of failure matter on launch day.
Give each tester a fixed half day. Two hours squeezed between phone calls across a month of interruptions finds almost nothing, while a booked day finds the awkward cases.
Name one person to coordinate. That person assigns scripts, collects results and chases the vendor, because without one, defects arrive by phone call and chat message and are quietly lost.
Test with your own data, not the demo set
Ask the vendor to load your real customers, items, price lists and a few months of past transactions into a staging copy of the live setup. Mask phone numbers and bank details.
Real data exposes what demo data hides. Names with apostrophes, a product with forty variants, a customer who pays in two currencies and a date that falls on a leap day all break things. Run the same invoice through the old process and the new screen, then compare the tax lines, rounding, totals and the printed layout that your customers receive.
Replay awkward past cases. Pick a returned order, a part payment and a month-end close, then compare three customer statements and the aged debtor report with the old figures. Note every difference as a defect.
- Imported customer and item masters, row counts checked
- Three awkward past transactions replayed
- Reports compared with figures from the old system
- User roles set up exactly as in production
Log defects so each one can be retested
Use one shared tracker, never email. Every defect carries the criterion number, the steps, what happened, what was expected, a screenshot and a severity of blocks work, has a workaround, or looks wrong. The owner sets severity, not the vendor. A missing rounding rule that costs the accounts team ten minutes every day matters far more than a button colour, so the owner ranks it above cosmetic complaints.
The vendor fixes the item and marks it ready, then the original tester retests the same steps and closes it with a date. Nobody closes their own defect.
After each fix, rerun a handful of earlier passed scripts, because a repair on one screen often breaks a neighbour that nobody thought to recheck.
What the sign-off sheet should say before final payment
Sign-off is a document, not a handshake. List every criterion with its result and date, list open defects with agreed severity and a fix date, and state which version number and build was tested.
Link the last payment to the sheet. Hold back the final instalment until blocking items are closed, and agree a warranty period in which later defects are fixed free of charge. Name the warranty period, the response time for each severity and the person at the vendor who answers, so late defects have a path.
Before you sign, confirm that you hold the source code access, admin credentials, data export and handover notes the contract promised. Then book the go-live date.
Acceptance test and sign-off sheet
A two-page worksheet. Page one is a table with columns for criterion number, scope clause, steps, expected result, tester, date, pass or fail and defect number. Page two holds the sign-off block: software version tested, open defects with severity and fix date, handover items received, warranty start date, and signature lines for owner and vendor.
Open a blank worksheet to printQuestions owners ask
Who should do user acceptance testing?
The people who will use the software every day, such as the clerk, the dispatcher and the manager, with one coordinator keeping scripts and results in order. Vendor testers cannot replace them. Pair each tester with a written script, so even a nervous first-timer produces a result that someone else can read and repeat.
How long does acceptance testing take?
It depends on the number of criteria and testers, so block fixed days rather than spare hours and plan for at least two rounds because fixes need retesting.
Can we refuse to sign if the software has defects?
You can withhold sign-off for blocking defects that break a written criterion, while cosmetic items are usually listed and fixed under warranty. Check what your contract says.
What if the vendor says the defect is a new request?
Compare it with the written criterion. If the criterion covers it, the item is a defect; if not, it is a change request with its own estimate and its own approval.