User Acceptance Testing: 7 Business Checks Before Launch

User acceptance testing checks whether software supports the work your business needs to perform. Business users run realistic tasks, compare the results with agreed requirements and record gaps before launch. It answers a practical question: can the people who depend on this system use it to complete their work correctly?

A developer’s successful demo does not answer that question on its own. Users need to test normal tasks, exceptions, permissions and data. This article explains how to plan UAT, write useful scenarios, manage defects and make a clear release decision.

What user acceptance testing covers

UAT focuses on business acceptance. For example, a finance user might confirm that an approved order produces the correct invoice details. A dispatcher might verify that a reassigned job appears for the right technician. These checks follow the business process across screens.

Meanwhile, other tests serve different purposes. Unit tests check small parts of code. Integration tests check how components work together. Performance tests explore speed and capacity. UAT does not replace those checks, even when users find technical defects during their work.

Atlassian’s user acceptance testing template shows how structured test records help teams compare actual and expected results. The useful principle is consistency. Testers should record enough detail for the team to repeat a failed task and understand its business impact.

Choose testers who know the real workflow

Select people who perform the work daily, along with the owners who can approve business rules. A manager may understand priorities but miss a small exception that frontline staff handle every afternoon. So, include both perspectives.

For a client portal, include someone who understands the client’s task as well. Internal users often know shortcuts that clients will not discover. A system can satisfy an internal process while still leaving an external user unsure what to do next.

Assign a UAT coordinator to organize scenarios, access, questions and progress. Also assign an owner for the final decision. Without those roles, the team may finish testing but still disagree about whether the release is ready.

Set entry conditions before testing starts

UAT works best when the team can test a stable version in a suitable environment. First, confirm that developers have completed the agreed scope and basic technical checks. Next, check that integrations and sample records support the chosen scenarios.

Document the version under test. If developers change it during a test cycle, record which cases need another run. Otherwise, one tester may approve a behavior that no longer exists in the latest release.

• Agreed requirements and acceptance criteria are available.
• Test users have the correct roles and access.
• The environment contains realistic data.
• Critical integrations have a safe test route.
• Testers know where to record results and ask questions.
• The team has agreed how to classify defects.

Do not use UAT as the first place to discover whether the app opens. Users should spend their time assessing business behavior. Our article on product design and development explains why early user review should begin before this final acceptance stage.

Write scenarios around outcomes

A strong scenario starts with a business task, not a tour of buttons. Instead of asking a tester to open every menu, ask them to create and approve a request within their role. Then check the resulting record, notification and downstream action.

Give each test a short identifier, purpose, starting condition, steps and expected result. Keep the expected result specific. “It works” tells the team little. “The request changes to Approved and records the manager’s name” gives them evidence to assess.

Also describe the test data. If a rule depends on value, date or status, those details matter. So, use records near the rule boundary as well as ordinary records.

Test seven types of business behavior

1. The complete normal process

Follow the main task from start to finish. For an order workflow, this may include creation, approval, fulfillment and reporting. But, do not stop after the first screen looks correct. Later steps may reveal missing data or conflicting statuses.

Use the roles that would perform each step in real life. Switching everyone to an administrator account can hide permission problems. So, check the handoff between users, not only the actions within one account.

2. Missing and invalid data

Try incomplete records, duplicate references and invalid dates. The app should explain the problem in terms the user understands. A technical error message may reveal a defect, but it does not help staff correct their entry.

Also check whether the form keeps valid data after an error. If a user loses a long set of notes because one field fails validation, the workflow may create avoidable rework.

3. Access and record boundaries

Confirm that each role can perform its own work and cannot access another role’s restricted actions. In addition, try records from another branch or client account. A hidden menu does not prove that direct access is blocked.

Ask the technical team to support tests that attempt a protected action directly. Users do not need to write technical requests themselves. But, acceptance should cover the business rule behind those requests.

4. Changes and cancellations

Real workflows include corrections. Test what happens when a user edits a submitted record, cancels a task or reopens a rejected request. Also check whether earlier approvals still apply after a material change.

For example, a price increase might require another approval. If the software lets a clerk change the value after sign-off without review, the approval process no longer protects the planned decision.

5. Integration failures

Try a delayed or failed response from a connected system through a safe test method. Confirm that the app shows a clear state and avoids duplicate transactions on retry. Meanwhile, staff should know whether they can continue or need to wait.

Our article on backend development services explains why these interactions need server-side controls. UAT should confirm the visible business outcome of those controls.

6. Migrated and historical data

Check realistic old records after migration. Look at relationships, totals, status values and date formats. A successful import count does not prove that staff can use the records correctly.

Microsoft’s guidance on UAT after data migration highlights the need to test business use of migrated data. So, select examples that cover old, active and unusual records, rather than reviewing only a recent clean sample.

7. Reports and exports

Compare a report with known source records. Confirm filters, totals, date boundaries and access. Also test an empty result and a larger export. A report can look polished while quietly excluding valid transactions.

Use independent checks where possible. For example, finance can calculate a small sample total outside the app. That avoids accepting one incorrect screen because another screen shows the same error.

Use realistic data safely

Choose data that resembles real work without exposing more private data than needed. Synthetic records often suit common scenarios. But, a migration test may need a controlled sample of actual structures and relationships.

Remove or mask sensitive fields where practical. In addition, prevent the test environment from sending real invoices, messages or payments. Use test destinations and make the environment’s identity visible.

Give each tester a repeatable starting state. If one person changes a shared record, another test may fail for the wrong reason. Separate data sets or a reset process can make results easier to trust.

Record defects so developers can reproduce them

A useful defect record includes the test version, account role, record reference, steps, expected result and actual result. Attach a screenshot when it clarifies the problem. But, a screenshot alone rarely explains the full path.

Describe business impact separately from technical severity. A small rounding issue may block finance even if the app stays online. Meanwhile, a visual alignment issue may have little effect on a critical task.

Distinguish a defect from a new request. If the software violates an agreed rule, that is a defect. If users discover a better process, it may require a change decision. Both matter, but they should not enter the same queue without context.

Retest fixes and protect nearby behavior

After a fix, rerun the failed test with the same conditions. Next, test nearby cases that the change could affect. A fix to an approval limit might alter another role’s behavior or change an export.

Keep evidence from the original failure and the successful retest. This gives the business owner a clear trail. It also prevents a defect from closing merely because someone says the code changed.

For a phased product, avoid expanding the UAT scope without a release decision. Our article on MVP software development explains why each release should deliver a complete, agreed outcome.

Make an explicit go-live decision

Define exit conditions before the first test. For example, all essential scenarios may need to pass, while named minor defects can remain with an agreed plan. The business owner should accept any residual risk explicitly.

Do not hide untested areas behind a percentage. A high pass rate can still exclude the one process that controls payments. Instead, review critical workflows, open defects, support readiness and recovery steps.

Sign-off should find the version, scope, known issues and decision owner. In addition, confirm training and launch support. Acceptance evidence helps the release decision, but it does not replace an daily plan.

Plan a UAT schedule around actual staff capacity

Testers still have daily work to perform. Reserve time for testing instead of assuming people will fit it between client tasks. A named test session often produces clearer evidence than scattered clicks over several weeks.

Group scenarios by workflow and role. For example, purchasing can create requests before managers test approval and finance tests payment status. This sequence makes the handoffs visible without forcing every tester to wait for everyone else.

But, keep independent starting records where possible. A defect in one scenario should not prevent the team from checking every unrelated workflow. The coordinator can prepare separate examples for cancellation, rejection and normal completion.

Leave time for fixes and retests. A schedule that ends immediately after the first test cycle assumes the system has no meaningful defects. Instead, agree on a review point where the team can assess progress and adjust the release date if needed.

Also record not available testers and untested tasks. Do not mark a workflow as accepted because its owner could not attend. Assign another qualified reviewer or carry the gap into the release decision explicitly.

Last, keep daily reporting short. Show completed critical scenarios, blocked tasks and decisions that need an owner. That gives the business useful progress without burying it in a raw defect list.

Test the work before you approve the system

User acceptance testing should produce evidence that your people can complete their real tasks. Start with clear outcomes, cover exceptions and retest fixes. Then make a release decision based on the workflows that matter most.