User acceptance testing asks whether a business application supports the work people need to do. It is the point at which actual users examine realistic tasks, outcomes and handovers, rather than simply watching a supplier demonstrate features. A screen can look finished while the workflow behind it remains unsuitable for daily operations.
For a bespoke application, acceptance should be planned alongside requirements. The team needs to know which business outcomes must be demonstrated, who can judge them and what evidence supports the decision to launch. Leaving these questions until the final week makes disagreements harder to resolve.
A useful UAT plan combines representative people, realistic data, meaningful scenarios and clear decisions. It also distinguishes business acceptance from other testing, so a positive user review is not mistaken for evidence that performance, security and recovery have all been verified.
Define what the business is accepting
List the workflows and outcomes within the release. For each, identify the business purpose, affected roles and the expected result. “The application has an order screen” describes a feature. “An authorised operator can create a valid order and pass it to fulfilment with the correct information” describes work to assess.
Link the scenarios to agreed requirements and acceptance criteria. If an important behaviour has never been defined, resolve it before asking testers to approve it. Otherwise, one person may judge the screen against current practice while another assumes a new process.
Keep the release boundary visible. Some features may be planned for later, while existing systems remain responsible for other tasks. The acceptance plan should test the handovers that belong to the current release and record which wider capabilities are outside it.
User acceptance testing has a distinct purpose from component and process tests: business users assess whether the application is ready for its intended work. Define the scenarios and acceptance responsibilities for the bespoke application rather than substituting a technical demonstration. Our software testing and acceptance guide provides the related checks.
Select users who represent the real operation
Include people who perform the work, supervise it and receive its outputs. A manager may understand the business goal without knowing every exception an operator handles. An experienced user may understand the old system but need support to evaluate a changed process fairly.
Choose a practical mix of roles and experience levels. Include the people whose permissions or tasks differ materially, such as an approver, a service administrator and a reporting user. A single highly privileged account cannot demonstrate that each intended role can complete its work correctly.
Explain the new process before testing begins. Users should know what has deliberately changed and how the application is intended to work. UAT should reveal whether that design supports the business, rather than become an accidental test of who can guess an unfamiliar interface.
Allocate time away from normal duties where possible. Rushed testing between urgent customer tasks encourages people to approve what they have seen without exploring the important scenarios. Name a coordinator who can organise sessions, answer procedural questions and keep evidence together.
Build scenarios around complete tasks
Start with a normal journey and follow it through to the business outcome. For an order application, that might include finding a customer, choosing the correct items, checking relevant details, submitting the order, receiving it in fulfilment and verifying the resulting record.
Add variations that occur in real work. Consider missing information, an amended order, a duplicate request, a rejected approval or a cancelled task. These scenarios often expose assumptions that a supplier's ideal demonstration does not exercise.
Test handovers between roles and systems. Confirm what the next person receives and whether they can continue without re-entering information unnecessarily. Where an integration is involved, inspect both sides of the exchange rather than treating the first system's success message as proof of completion.
Specify the expected outcome for each scenario, including important totals, status changes or notifications. Give testers enough detail to make an objective assessment while allowing them to report unexpected behaviour beyond the scripted steps.
Prepare representative data and an appropriate environment
Use data that reflects the structures and variations the live system will encounter. Include long names, relevant date boundaries, realistic volumes for the task and records with optional fields absent. A tiny set of perfectly complete examples can hide practical problems.
Arrange data use through the project's agreed handling rules. Representative synthetic or appropriately transformed data may be suitable, depending on the task. Do not copy sensitive production records casually into a shared demonstration environment merely because they are convenient.
Confirm the application version, configuration and connected systems before each cycle. Record what is being tested, so a result can be associated with the correct build. If the supplier changes the application during a session, identify which cases need to be repeated.
Provide the intended roles and realistic permissions. Make sure testers can access the environment, recover their accounts and locate the instructions. Resolve setup problems early so the allocated acceptance time is spent assessing the workflow.
Record evidence and classify issues clearly
Use a consistent result record containing the scenario, tester, environment, build, actual outcome and supporting evidence. A screenshot or a short reproduction sequence can help, but it should be accompanied by an explanation of what the user expected and why the difference matters.
Distinguish a defect from an unclear requirement, a training issue and a requested enhancement. The categories influence the response. A calculation that contradicts agreed rules needs correction; a newly requested report may need a separate scope decision.
Assess priority through business impact and available alternatives. An issue that prevents fulfilment for a common order deserves a different response from a cosmetic inconsistency on a rarely used screen. Record the reason rather than relying only on a label such as “high”.
Make the reporting process easy enough that users actually use it. Ask for concise, reproducible information and let the coordinator help refine incomplete reports. Testers should not need to diagnose the code before they can report a failed task.
Plan fixes, retesting and wider checks
Leave time for the supplier to investigate, correct and return issues for retesting. The person confirming a fix should repeat the relevant task and inspect the business outcome. A note that the supplier has changed the code is not the same as an accepted result.
Identify related cases that may be affected by a fix. A change to order totals might influence approval rules, invoices and reporting. Coordinate regression testing with the technical team, so the project assesses these dependencies rather than checking only the originally failing screen.
Keep specialist testing responsibilities explicit. Performance, security, accessibility, backup recovery and deployment readiness may require separate work and expertise. UAT can reveal concerns in these areas, but it should not be presented as a substitute for their agreed verification.
Maintain a visible status for each issue and scenario. The release decision needs to distinguish passed tests, failed tests, cases awaiting retest and cases never attempted. Counting all completed sessions as successful can conceal important gaps.
Make acceptance a documented business decision
Agree the launch criteria before the final review. Identify which outcomes must pass, which unresolved issues can be accepted with a workable arrangement and who has authority to make that decision. Avoid inventing a relaxed threshold simply because the planned launch date is close.
Document any accepted limitation, its business impact, the temporary process, the owner and the intended resolution. A vague statement that users are happy provides little guidance once the application becomes part of daily work.
Bring the UAT evidence together with training, support and operational readiness. Giraffe Digital's digital strategy service considers the systems within a business journey. Planning acceptance around that journey helps the organisation choose a launch based on demonstrated outcomes and understood responsibilities.
Frequently asked questions
How should we define what the business is accepting?
List the workflows and outcomes within the release. For each, identify the business purpose, affected roles and the expected result. "The application has an order screen" describes a feature. "An authorised operator can create a valid order and pass it to fulfilment with the correct information" describes work to assess. Link the scenarios to agreed requirements and acceptance criteria. If an important behaviour has never been defined, resolve it before asking testers to approve it. Otherwise, one person may judge the screen against current practice while another assumes a new process. Keep the release boundary visible. Some features may be planned for later, while existing systems remain responsible for other tasks. The acceptance plan should test the handovers that belong to the current release and record which wider capabilities are outside it.
How should we build scenarios around complete tasks?
Start with a normal journey and follow it through to the business outcome. For an order application, that might include finding a customer, choosing the correct items, checking relevant details, submitting the order, receiving it in fulfilment and verifying the resulting record. Add variations that occur in real work. Consider missing information, an amended order, a duplicate request, a rejected approval or a cancelled task. These scenarios often expose assumptions that a supplier's ideal demonstration does not exercise. Test handovers between roles and systems. Confirm what the next person receives and whether they can continue without re-entering information unnecessarily. Where an integration is involved, inspect both sides of the exchange rather than treating the first system's success message as proof of completion.
How should we prepare representative data and an appropriate environment?
Use data that reflects the structures and variations the live system will encounter. Include long names, relevant date boundaries, realistic volumes for the task and records with optional fields absent. A tiny set of perfectly complete examples can hide practical problems. Arrange data use through the project's agreed handling rules. Representative synthetic or appropriately transformed data may be suitable, depending on the task. Do not copy sensitive production records casually into a shared demonstration environment merely because they are convenient. Confirm the application version, configuration and connected systems before each cycle. Record what is being tested, so a result can be associated with the correct build. If the supplier changes the application during a session, identify which cases need to be repeated.
How should we record evidence and classify issues clearly?
Use a consistent result record containing the scenario, tester, environment, build, actual outcome and supporting evidence. A screenshot or a short reproduction sequence can help, but it should be accompanied by an explanation of what the user expected and why the difference matters. Distinguish a defect from an unclear requirement, a training issue and a requested enhancement. The categories influence the response. A calculation that contradicts agreed rules needs correction; a newly requested report may need a separate scope decision. Assess priority through business impact and available alternatives. An issue that prevents fulfilment for a common order deserves a different response from a cosmetic inconsistency on a rarely used screen. Record the reason rather than relying only on a label such as "high".
How should we make acceptance a documented business decision?
Agree the launch criteria before the final review. Identify which outcomes must pass, which unresolved issues can be accepted with a workable arrangement and who has authority to make that decision. Avoid inventing a relaxed threshold simply because the planned launch date is close. Document any accepted limitation, its business impact, the temporary process, the owner and the intended resolution. A vague statement that users are happy provides little guidance once the application becomes part of daily work. Bring the UAT evidence together with training, support and operational readiness. Giraffe Digital's digital strategy service considers the systems within a business journey. Planning acceptance around that journey helps the organisation choose a launch based on demonstrated outcomes and understood responsibilities.
