User acceptance testing: a practical guide for business owners

User acceptance testing asks whether the delivered software supports the business tasks and acceptance criteria agreed for the release. The people responsible for those tasks should take part. Developers bring technical knowledge, but a person who prepares quotations, approves leave or handles customer enquiries can recognise practical problems that a technical demonstration may overlook.

Distinguish this review from other testing. Technical tests check implementation behaviour. Usability research investigates whether people understand and can use an experience. Security, accessibility and performance reviews address their own questions. These activities can inform one another, but a successful business walkthrough does not establish that every technical or operational requirement has been met.

Agree the boundaries before starting. Identify the release being assessed, the workflows included and the evidence needed for acceptance. If a function was explicitly deferred, record that fact rather than treating it as a missing delivery. If the scope is unclear, resolve it against the approved requirements before asking testers to make a decision.

Name someone on the client side to coordinate testing and bring together the findings. This person needs enough understanding of the work to resolve conflicting feedback and enough authority to obtain decisions. They do not need to write code. Their job is to make sure the right tasks are checked and that outstanding questions reach the people who can answer them.

Include representatives of the roles that matter. A customer, a service operator and a manager may interact with the same record in different ways. Finance staff may need to verify totals and exports, while a support colleague checks how an incorrect submission is corrected. Testing everything through an administrator account hides many of these differences.

Give participants a short orientation, the agreed scope and time to work through scenarios. Explain how to report a problem and who will help if the environment fails. Avoid leaving the entire review to one busy employee on the afternoon before launch. Schedule enough time for fixes to be retested and for the business to consider the result.

Choose scenarios from the tasks the product exists to support. Start with the event that begins the work and follow it until the expected business outcome is visible. A contact form scenario should include submission, receipt by the intended team and the information needed for a reply. A confirmation message on the website checks only one part of that journey.

For a quotation platform, a representative scenario might involve creating a customer, adding labour and materials, applying the agreed discount, obtaining approval and converting the accepted quotation into a job. Then check what the customer receives and which version staff can review afterwards. This is an illustrative test flow; the correct steps depend on the product being assessed.

Give each scenario a clear expected result. A statement such as the report works is too open to interpretation. Specify the period, source records, calculation and expected output. The tester should be able to determine whether the result matches without asking the developer to interpret it. Keep the steps understandable to someone who normally performs the work.

Use a test environment and accounts that are suitable for the review. It should resemble the intended release closely enough for the results to mean something. Record important differences, such as a payment sandbox, disabled outgoing messages or a smaller dataset. Otherwise, testers may mistake an intentional limitation for a defect or overlook a behaviour that has not actually been exercised.

Prepare fictional or appropriately anonymised records covering normal variations: long customer names, different dates, several line items, empty optional fields and records in different statuses. For calculations, agree sample inputs and independently checked expected totals. Do not make every example so simple that it avoids rounding, revisions or other rules that affect ordinary work.

Control external effects. Test emails should reach designated test recipients, payment tests should use the appropriate sandbox and imports should not overwrite live records. Agree how test data will be reset between runs. If the test requires sensitive information, establish the access and handling arrangements before copying it into a new environment.

Run scenarios with the role that would perform them in practice. Check whether a person can see the right records and complete authorised actions. Also check that they cannot perform actions reserved for another role. Where branches or organisations share one application, include a review of which records each account can access.

Follow approval rules through rejection, revision and resubmission. If a manager rejects a request, staff should understand its status and know what they can change. Where a sent or approved document must be preserved, verify that editing a draft does not silently alter the accepted record. Business users should confirm these observable behaviours alongside the development team’s technical checks.

Include predictable failures: an expired invitation, an unsupported file, a duplicated submission or a temporarily unavailable integration. Check whether the software explains the problem, preserves appropriate work and offers a safe next step. The business also needs to know which exceptions require a support request and how that request reaches the right person.

The screen where a record is entered is only part of a business system. Review the emails, PDFs, exported files and reports created from it. Check names, dates, statuses, totals and business details against the source record. Make sure the recipient can understand the document without access to the internal interface or an explanation from its creator.

Reconcile a small, known set of records through the reporting workflow. Create the records, change their statuses where appropriate and verify which ones the report includes. Test the relevant date filters and export. A plausible total is not enough if the business cannot explain which transactions contribute to it or why cancelled work is included.

For integrations, distinguish a successful request from a completed business outcome. An application may accept an email for sending while the intended recipient never receives it. Review the evidence available at each stage and document any stage the test environment cannot confirm. Arrange a controlled live check where necessary, with the right owner and safeguards.

Choose devices and browsers based on the people who will use the software. A customer booking on a phone and an employee processing records on a laptop face different layouts and input methods. Test the actual tasks on relevant equipment, including file selection, date entry, document viewing and the on-screen keyboard where those actions matter.

Observe whether people can follow labels, instructions and error messages without coaching. Check basic interactions such as keyboard navigation, visible focus, zoom and readable text. Include users with relevant access needs in the wider evaluation. Record barriers so they can be investigated rather than treating them as individual preferences.

Keep the limits of this exercise clear. A small group of testers cannot establish accessibility for every user, and automated scans cannot establish it alone either. Similarly, a page feeling fast on one office connection does not establish performance under expected demand. Ask for the separate evidence appropriate to the product and its release requirements.

A useful defect report explains the task, the account role, the inputs, the steps taken, the expected result and what actually happened. Include the environment and release version where available. A screenshot can show the wrong result, while a short recording can clarify a sequence. Remove private details that are unnecessary for investigating the issue.

For example, report that a quotation total changes after saving when a particular discount is applied, with the sample amounts and expected calculation. A message saying the quotation screen is broken gives the developer much less to work with. Keep one issue per record so that its fix, retest and status can be tracked independently.

Separate defects from new requests and questions. A missing agreed approval rule is different from a newly suggested dashboard. Both may deserve attention, but treating them as the same category creates disagreement about delivery. Where the requirement is ambiguous, record the decision made and whether it changes the release scope or acceptance criteria.

Agree priorities using the consequence of the problem. An incorrect financial calculation, inappropriate access or inability to complete a core task may prevent acceptance. A minor spacing issue may have a different priority. Consider how often the issue occurs, who is affected and whether a practical workaround exists without introducing further risk.

A workaround needs a clear owner and a realistic limit. Asking staff to check every total manually may undermine the purpose of the software. A short-term manual step for a rare exception could be acceptable if the business understands the effort and approves it. Record the reasoning instead of assigning every issue the same urgent label.

After a fix, rerun the original scenario with the same inputs. Then check related behaviour that might have been affected. A change to quotation calculations may require another check of the PDF, approval view and report totals. Keep the result against the issue record and identify the tested version. A developer marking an issue fixed is the start of the retest, not its conclusion.

At the end of the review, summarise the scenarios completed, results, unresolved issues and evidence still missing. Name the person authorised to accept the release. The decision should identify the version and scope being accepted, rather than vaguely approve the entire product and every future change.

If the business accepts a release with outstanding work, list each item, its impact, any temporary process and the agreed next action. Keep the decision consistent with the project agreement and the organisation’s approval process. Acceptance should not depend on testers pretending an unresolved problem has disappeared, or on a supplier treating silence as evidence of successful testing.

Before launch, confirm operational ownership as well: support contacts, access, training, monitoring and the changeover plan. User acceptance testing establishes whether the agreed business scenarios work; release readiness also depends on those surrounding arrangements. aaliSoft can help turn requirements into reviewable scenarios, coordinate fixes and prepare a clear handover so clients can approve work with evidence behind the decision.