User acceptance testing checklist for custom business software

List every role that will log in, from counter clerk and store keeper to dispatcher and auditor, then write the five jobs each does weekly. Those jobs become your test cases.

Write each case like a note to a new colleague: raise a sales order for a credit customer, cancel one line, and state the expected result.

Hand each case to the person who does that job today, because a developer clicking through proves only that the menus open. Add the traps only users know. A clerk tries to open payroll, a session times out mid entry, an accented customer name breaks a label, and a CSV export opens oddly in Excel.

Have the vendor import last month’s customers, item master and transactions into the test copy, since invented data hides awkward cases like a customer with two billing addresses. Test the item sold by carton and loose.

Pick the worst month, because one with credit notes, part payments, a price revision and a late supplier bill will expose more faults than a quiet one.

Include stock transfers between depots, batch expiry dates, a thermal roll print and an A4 preview, and keep the old system running beside the new one. You need it for the next check.

Reports win or lose trust. Run the trial balance, stock valuation, receivables ageing and sales by customer in both systems for identical dates, then put the totals side by side on one sheet.

Every gap has a cause. Rounding, a back dated voucher and an opening balance keyed twice are the usual suspects, so ask the vendor to explain every gap in writing.

Do not trust luck. Trace one invoice from entry to ledger to report, then one purchase return, then one cheque bounced after deposit, and note every screen where the figure changed hands.

A vague report wastes a week. Record the login role, the exact clicks, the record used, what you expected and what appeared, and attach a screenshot showing the browser address bar.

Rate each defect with one of four labels, blocks daily work, wrong figure, awkward but workable or cosmetic, and agree those labels with the vendor before testing starts.

Keep one shared register where everyone sees what is open, fixed or waiting for retest, so nobody argues about status on the weekly call with the vendor. No private spreadsheets allowed.

Write down what passing means, for example no open defect that blocks daily work or shows a wrong figure, and every role has run its cases twice. Cosmetic items can wait on a list.

Sign off by role. One signature is not enough. The accountant confirms the ledger, the store keeper confirms stock, and the owner signs last, after reading the open defect list and the report reconciliation sheet.

Then plan the first live week. Name who watches the first invoice run, and keep the old system readable through one full month end so late questions still have an answer.