User acceptance testing: a business checklist

Test tasks rather than screens

Opening every page does not show that a customer request can be completed correctly. Start with a realistic scenario, identify the user and write down the expected outcome. Include what should be stored, displayed and sent to connected tools.

An illustrative scenario might be: a dispatcher assigns a job, a worker marks it complete and the manager sees it in the correct report. Each step should produce an observable result.

Prepare a small test pack

Include the unsuccessful paths

Test missing information, duplicate submissions, cancellations and expired sessions. Try to view a record as the wrong customer or a restricted staff member. Check that errors are understandable and that retrying does not duplicate work.

Do not treat security testing as complete because users cannot see a menu item. Ask the developer to demonstrate that the underlying action is protected too.

Use the devices people actually use

A workflow tested only on a large office screen may fail for a worker using a phone. Test keyboard navigation and important assistive technology needs as part of usability. W3C guidance provides a useful basis for accessibility checks, but a quick checklist is not a complete accessibility audit.

Report defects so they can be reproduced

Include the account role, steps, expected outcome and relevant screenshot without exposing personal information. Separate a defect against agreed behaviour from a new feature request. Both can matter, but they have different implications for scope and release decisions.

Make the launch decision explicit

Agree blocking issues in advance: incorrect access, lost records or a core workflow that cannot complete should not be hidden behind a high pass percentage. Document accepted limitations, their workarounds and who approved them.

After fixes, repeat the affected scenario and related tasks. A successful retest of one button does not prove the whole workflow still works.