A custom application can pass its automated tests, load quickly and meet every documented feature requirement, yet still fail on the first day of real business use. An order may be technically saved but routed to the wrong approval queue. A finance export may be accurate for one department and wrong for another. A supervisor may be unable to correct a record without calling an administrator. These are not always coding failures. They are failures to validate how the software supports the work.
User acceptance testing (UAT) is the structured business validation that happens before a system is accepted for production use. Its purpose is not to make business users repeat the development team’s quality assurance (QA). It is to establish whether the right people can complete the right tasks, with realistic data, under realistic constraints, and whether the remaining risks are acceptable to the organization.
For a CIO, COO or product sponsor, the critical question is not ‘Did everyone click through the screens?’ It is ‘Can we show evidence that the system is ready for the business processes it will run?’
UAT is a business decision, not another round of QA
Development testing asks whether software behaves as specified. Unit tests validate small components; integration tests examine interactions between systems; system and regression tests look for functional defects and unintended consequences. Security and performance testing address different technical risks. UAT asks whether the resulting behavior is suitable for the actual business operation.
A payment screen might pass functional tests because it accepts a valid payment and rejects an invalid card. UAT goes further: can a finance manager reconcile the transaction to the right invoice, identify a partial payment, investigate a duplicate submission and produce a usable audit trail? Those are acceptance questions rooted in operations, not merely in code.
The distinction should never become an excuse to send unfinished software to business users. UAT should start only when the build is stable enough for meaningful end-to-end validation, core defects have been addressed and the team can explain what is included in the release.
Who should test what? Assign ownership by business consequence
A successful UAT team is deliberately mixed. The project sponsor owns the decision to accept risk; process owners understand the intended outcomes; frontline users know the exceptions and workarounds; QA manages evidence and defects; developers diagnose and fix issues; IT and security validate operational controls. No single group can substitute for all the others.
Business sponsor: approve outcomes and residual risk
The sponsor should define which business outcomes are non-negotiable, who has sign-off authority and what constitutes a release blocker. They should review open high-impact defects and decide whether a controlled workaround is genuinely acceptable. A sponsor should not sign off simply because the planned testing window has ended.
Process owner: validate the complete workflow
The process owner should test an end-to-end journey, including approvals, handoffs, corrections and reporting. For a purchasing system, that means request, approval, purchase order, receipt, invoice match, exception resolution and downstream finance visibility. A workflow that works only when each step is isolated is not ready.
Frontline users: test the messy reality
Select representative users from different teams, locations, shifts, devices and experience levels. They should try common tasks and the situations that typically cause calls to support: missing attachments, wrong customer records, cancelled requests, overdue approvals, incomplete forms and interruptions mid-task. Avoid relying only on enthusiastic power users.
Finance, compliance and security: validate controls
Control owners should check permissions, approval thresholds, segregation of duties, audit history, reconciliation and retention where applicable. Their work should be tied to defined control requirements. A tester who can see a restricted record or bypass an approval is identifying a business risk, not a cosmetic defect.
QA, engineering and IT: enable testing without taking it over
QA should prepare test cases, maintain traceability, triage defects and verify fixes. Engineering should supply stable builds, logs, seeded data and responsive defect resolution. IT should test deployment, access provisioning, integrations, backups and operational monitoring. Business owners still need to decide whether the system works for them.
Start with a testable acceptance scope
Before inviting users, convert the release scope into a UAT matrix. For each critical workflow, identify its business owner, user role, preconditions, sample data, expected result, linked requirement, test evidence and severity if it fails. Include explicit exclusions so nobody mistakes ‘not tested’ for ‘passed.’
Prioritize by business impact and frequency. A low-frequency workflow can still be critical if its failure creates a regulatory breach, financial loss or operational shutdown. Conversely, a minor display inconsistency may be safe to defer. Make those trade-offs visible before testing starts.
The same discipline matters in custom web application development, where features, integrations and administrative roles often evolve together. A screen-by-screen checklist is rarely enough to prove a cross-system business process works.
Use realistic data without exposing production information
A clean sample record is useful for a demo but inadequate for acceptance. UAT data should include ordinary records, edge cases and known exceptions: duplicate names, missing optional fields, historical transactions, inactive customers, invalid addresses, different currencies, mixed tax treatments and records with multiple owners. Use a documented set of synthetic or properly de-identified records; do not copy sensitive production data casually into a lower-trust environment.
Keep the environment representative enough that permissions, configurations and integrations behave like production. Where a third-party service cannot be safely invoked, use an agreed sandbox or simulator and record the resulting coverage limitation. A mocked integration can validate application behavior but cannot prove the external provider will behave correctly in production.
For migration projects, reconcile record counts and financially significant totals between source and destination, then inspect exceptions at the record level. For reporting applications, compare important KPIs to approved reference calculations and confirm the data freshness users expect.
Test roles and permissions, not just features
A common UAT gap is testing each feature with an administrator account. That proves little about real access. Build a role matrix listing which actions each user type may view, create, approve, edit, export, delete or override. Then test both permitted and prohibited actions.
Consider a request that a junior analyst creates, a manager approves and a finance user exports. Test whether the analyst can improperly approve their own request; whether the manager sees only the relevant department; whether finance can access the supporting audit trail; and whether a suspended employee loses access. Include session expiry and reauthentication where those affect critical workflows.
Permission tests should cover the API and data access path as well as the visible interface. Hiding a button is not equivalent to enforcing authorization. Any significant access-control defect should be assessed by security and the business owner before release.
A practical UAT scenario: the order exception that exposes five gaps
Consider this hypothetical example, not a client case study. A distributor commissions an internal portal to resolve orders that cannot be shipped. The normal demonstration shows an agent opening an order, changing a delivery date and saving it. That is one happy-path test, not acceptance.
A meaningful UAT scenario begins with an order containing an unavailable item. The customer service agent marks it as an exception and proposes a substitute. A supervisor approves the substitute. Inventory availability changes before approval completes. The agent must see the updated status, avoid creating a duplicate reservation, inform the customer and leave a traceable history. Finance must see the correct adjustment in its export.
This single scenario tests state transitions, concurrency, role boundaries, customer communications, integration timing and reconciliation. The expected result must be explicit: what changes, what must not change, what the user sees when a conflict occurs and how the exception is recovered. If the portal silently overwrites the latest inventory state, the issue is a release risk even if every individual button works.
Design UAT cases that produce evidence
A useful case has an identifier, requirement reference, business owner, role, starting data, steps, expected result, actual result, pass/fail status, defect link and tester/date. Write expected results in business terms. ‘Save works’ is vague; ‘The approved request appears once in the finance export with the correct cost center and approval timestamp’ can be checked.
Do not over-script every click. Give less experienced testers clear instructions for high-risk scenarios, then allow exploratory sessions where experienced users try alternate paths. Record exploratory findings with enough detail to reproduce them. Keep screenshots or logs where useful, but do not collect sensitive information unnecessarily.
An effective UAT pack also contains a coverage view: critical workflows attempted, passed, blocked, failed or not run; defects by severity; outstanding dependencies; and the accountable owner for each gap. A percentage passed without context can hide a single catastrophic failure.
Defect severity should reflect business impact
Agree on severity definitions before UAT. One practical four-level model is: Critical, the business cannot operate safely or a major control fails; High, a critical workflow is broken without an acceptable workaround; Medium, an important function is impaired but a controlled workaround exists; Low, a minor usability or presentation issue with limited impact. Severity is impact; priority is the order in which the team will address the issue. They are related but not identical.
Every defect should capture the environment, role, steps, expected and actual behavior, relevant data identifiers and business consequence. Assign a single owner, target fix version and retest status. Duplicates should be linked, not counted as independent issues.
Use a daily triage meeting during the active UAT window. Business owners explain impact; QA checks reproducibility; engineers assess root cause and fix scope; the release owner decides priority. If a defect is deferred, document the workaround, affected users, monitoring plan and explicit acceptance by the appropriate business authority.
Retest fixes and run targeted regression
Closing a ticket after a developer says ‘fixed’ is not validation. The original tester or a designated representative should rerun the failed scenario in the correct build and record the result. Then QA should test adjacent workflows that may have been affected by the change.
If an approval-rule fix touches shared permissions logic, regression may need to cover other roles and departments. If an integration mapping changes, retest both normal records and the exceptions that previously passed. Reserve time for this cycle; an UAT plan that ends the moment defects are reported is incomplete.
Define entry and exit gates before the test window
Suggested entry criteria
The release candidate is deployed to a controlled environment; planned scope and acceptance criteria are frozen for the test cycle; smoke tests pass; test users and role assignments are provisioned; representative data is available; integrations or agreed substitutes are ready; known defects and limitations are disclosed; and testers know how to record evidence.
Suggested exit criteria
All critical workflows have been executed or explicitly waived by an authorized owner; no unresolved Critical or unaccepted High defects remain; failed cases have been retested; key integrations and reconciliations have been checked; required security and operational controls have been approved; support and rollback arrangements exist; and the business sponsor signs a release decision with the remaining risks attached.
These are example gates, not universal thresholds. A regulated workflow may require stricter evidence and independent approval. A low-risk internal enhancement may need less ceremony. The governing principle is proportionality: rigor should follow the consequence of failure.
The go-live decision needs more than a green spreadsheet
A release readiness pack should contain a one-page executive summary, scope and exclusions, scenario coverage, open defects by severity, security and integration status, data reconciliation, operational readiness, training readiness, rollback criteria and named signatories. Include a clear recommendation: go, conditional go or no-go.
Conditional go-live is appropriate only when the unresolved issue has a bounded impact, an approved workaround, an accountable owner and a date for remediation. ‘We’ll fix it later’ is not a risk treatment. When the system will process payments, patient information or other sensitive transactions, involve the relevant control owners in the decision.
Plan a hypercare period after launch. Monitor critical transactions, exception queues, user support tickets, integration failures and unexpected data changes. Agree on escalation paths and a rollback trigger before users depend on the new workflow.
A four-week UAT preparation and execution plan
Week 1: map the business and agree the gates
Identify the top workflows, high-risk exceptions and user roles. Confirm acceptance criteria and the business owner for each scenario. Establish severity definitions, defect workflow and sign-off authority. Confirm which nonfunctional requirements are separately covered by security, performance and technical testing.
Week 2: build data, accounts and the test pack
Prepare realistic synthetic data and role-specific accounts. Configure the environment, validate interfaces, test reporting outputs and conduct a short smoke test. Walk through the UAT pack with testers so ambiguities are removed before the formal window.
Week 3: run business testing and daily triage
Execute critical journeys first, followed by normal workflows and exploratory testing. Capture results and evidence centrally. Triage defects each day and keep the business sponsor informed of blockers rather than waiting for a final presentation.
Week 4: retest, regress and make the release decision
Verify fixes, run risk-based regression, complete reconciliations and review operational readiness. Produce the release readiness pack and obtain named approvals. If the gates are not met, extend or narrow the release rather than manufacturing a pass.
Metrics executives should actually review
Track critical-workflow coverage, not just total test count. Show pass/fail/blocked status by workflow and business owner. Monitor Critical and High defects still open, average age of unresolved blockers, percentage of fixes successfully retested, role coverage, reconciliation exceptions and unresolved production-readiness dependencies.
Use trend charts carefully. A sudden rise in defects can indicate productive exploration rather than deteriorating software quality; a low defect count can indicate weak testing. Pair quantitative indicators with a concise narrative explaining what the team learned and which risks remain.
Common UAT mistakes that make go-live riskier
The most damaging mistakes are predictable: inviting only managers rather than daily users; using administrator credentials for every test; relying on clean demo data; skipping downstream reconciliation; starting UAT before the build stabilizes; confusing test execution with approval; ignoring defect retests; and letting a project deadline override predefined release gates.
Another mistake is treating UAT as a one-time ceremony at the end of a long build. Regular business demonstrations and early workflow reviews reduce surprises. UAT should confirm an evolving shared understanding, not reveal for the first time what the product was supposed to do.
Frequently asked questions
1. What is UAT in custom software?
User acceptance testing is business-led validation that a software release supports agreed workflows, roles, controls and outcomes well enough to be accepted for use. It complements rather than replaces technical testing.
2. Who should own UAT?
A named business process owner should own acceptance of each critical workflow. A product owner or project lead coordinates the test cycle, QA manages evidence and defects, and an authorized sponsor makes the final release decision.
3. Should developers perform UAT?
Developers should support UAT by explaining behavior, providing logs and fixing defects. They should not be the only people deciding whether the business outcome is acceptable. Independent business participation is essential.
4. How is UAT different from QA?
QA primarily establishes whether the software meets technical and functional specifications. UAT establishes whether real users can complete the business process and whether the organization accepts the remaining operational risk.
5. How many UAT cases are enough?
There is no defensible universal number. Start with complete coverage of high-consequence workflows and key role/exception combinations. Add lower-risk scenarios based on usage, complexity and the consequences of failure.
6. Can UAT use production data?
Only under approved security, privacy and governance controls. Synthetic or properly de-identified data is generally safer for a test environment. If production-like behavior cannot be replicated, document the limitation and add compensating validation.
7. What happens when a tester finds a defect?
Record the steps, data, role, expected result, actual result and business impact. Triage severity and ownership, fix or formally defer it, then retest and perform targeted regression before closing.
8. Can a product go live with open defects?
Sometimes, if the defects are low impact or have approved workarounds and the accountable sponsor explicitly accepts the residual risk. Unresolved critical failures or uncontrolled security and financial risks should normally block release.
9. Who signs the UAT certificate?
The authorized business sponsor or delegated process owner, with supporting input from QA, technology, security and operations. The sign-off should reference scope, evidence, exclusions and open risks rather than simply state ‘passed.’
10. What should happen immediately after UAT sign-off?
Complete deployment and rollback checks, user training, access provisioning, monitoring and support handover. During hypercare, review real transaction outcomes and exception queues against the acceptance assumptions.
Make acceptance evidence part of the delivery plan
UAT works best when it is designed alongside the product, not bolted on before launch. Teams evaluating custom solutions should ask prospective delivery partners how they trace requirements to business scenarios, provision safe test data, manage defects and prepare operational handover. Those answers are more useful than a promise that ‘testing is included.’
Actiknow describes an iterative delivery process covering discovery, prototyping, development, quality assurance, deployment and support. If your team is planning a custom business application and wants to define business acceptance and go-live responsibilities early, contact Actiknow to discuss the scope and testing approach.