How Business Teams Should Run User Acceptance Testing for Custom Software

Check whether the release is ready for business acceptance

User acceptance testing asks whether people can perform the work agreed for the release. It does not replace the development team's functional, security or performance testing. Before formal sign-off, confirm the requirements and acceptance criteria, an identifiable deployed version, a stable test environment, target-role accounts and reproducible sample records. If these are missing, fix the entry conditions rather than treating unresolved integration work as completed acceptance.

For example, “supports approvals” is too vague: does the scope include return, withdrawal or reassignment? Use the software requirements document to define the task's starting point, completion condition and exception paths before testing. The ISTQB acceptance-testing syllabus also relates business needs and acceptance criteria to testing; the project's agreed scope remains the controlling reference.

Rewrite requirements as real task-based test cases

Do not test by opening every menu item in turn. Write each case around one role completing one business task. Record the role, starting data, action, expected result and evidence. Include returns, repeated submissions, empty data and insufficient permissions where they can change the business outcome.

Consider a purchasing application in which a requester submits a purchase request, a manager approves or returns it, and a purchasing specialist sees approved work. The cases below are an adaptable pattern; replace the fields and process rules with those agreed for the actual project.

Scroll horizontally to view the complete test cases.

If an approval result must also reach ERP or OA, follow the case to the target system's actual state. A “success” message in the new application is insufficient. Confirm cross-system ownership with the ERP, CRM and OA responsibility matrix.

Prepare roles, data, environment and evidence

The business owner and delivery team should agree on the case list and distinguish must-pass cases for the initial release from later work. Test accounts should represent requester, approver, viewer and unauthorized roles, rather than a shared administrator login. Sample data should include normal records and missing fields, duplicate numbers, closed items or records from another department. Use masked or purpose-built test data when real personal or sensitive business information is involved.

For each run, record the environment, version, date, account role and sample record ID. If a configuration, interface or deployment changes during testing, rerun affected cases on the new version. A screenshot helps locate a problem but cannot alone prove a backend save, write-back or permission boundary.

Business and technical acceptance have different owners. Business users can judge whether a task and its result meet the agreed need. Interface logs, database migration, backup restoration and deployment security still require evidence from the responsible technical team. For an agreed private deployment, check critical paths in the target environment or an equivalent test environment.

Record actual outcomes, not just pass marks

1. Run the task: start at the agreed entry point with the specified role, without skipping pages likely to fail.
2. Check the final result: compare notifications with list, detail, history and connected-system states.
3. Record deviations: capture case ID, version, steps, actual and expected results, sample ID and reproducible evidence.
4. Retest after fixes: identify the fixing version and affected area, rerun failed cases and check adjacent flows.

“Handled” is not a useful defect status by itself. Separate not reproduced, awaiting fix, fixed awaiting retest, retest passed and explicitly deferred to another version. For an intermittent issue, keep the time, role and record ID so logs can be checked.

Which defects should block launch?

Agree on blocking conditions before testing begins. Typical blockers are a core task that cannot finish, saved data that disappears or creates duplicates, unauthorized access to another user's records, cross-system results that cannot be reconciled, or a failure presented as success without a workable manual recovery path.

Record visual details and minor copy issues as well, but decide whether they block launch based on user impact, available workaround and the agreed scope. A deferred issue must name affected users and scenarios, temporary handling, a repair owner and target version. “Optimize later” is not a decision.

A successful office-computer demo cannot stand in for agreed device, browser or network conditions that remain untested. For data dashboards, use the separate page, data, permission and deployment acceptance checklist; this article focuses on complete business tasks in custom software.

Write a sign-off with clear boundaries

The acceptance record should state the tested version and environment, cases executed, passed and failed items, resolution of blockers, and owner and retest date for deferred issues. The business owner confirms the actual results of listed tasks under listed conditions, not every future scenario, third-party interface or performance target.

A useful decision is explicit: “The mandatory first-release cases passed in the named version and environment; remaining items are recorded for agreed remediation and retest.” If a blocker remains, record “not accepted” and the evidence needed before the next review. Separately verify source code, accounts and deployment materials against the software project handover checklist so a successor team can maintain the system after business testing.