User Acceptance Testing (UAT) Guide: What to Do Before You Approve a Software Delivery
When a software vendor says “delivered,” the work is not finished: the real question is whether the system works in your actual workflows. We explain how to plan acceptance testing, which scenarios to try, how to prioritise findings and when to say “accepted.”
In brief: Acceptance testing (UAT, User Acceptance Testing) is software being tried by real users with real business scenarios and approved with “this meets our need.” The vendor's own tests (unit tests, integration tests, security scans) check technical correctness; acceptance testing confirms fitness for the business, and you know that best. A good UAT needs: 1) Acceptance criteria written in advance, 2) test scenarios derived from real workflows, 3) real users, 4) realistic (or anonymised) test data, 5) a system that prioritises and tracks bugs, 6) clear rules for the “acceptance” decision. Saying “we should have tried this too” after acceptance is very expensive, because acceptance usually triggers payment and the warranty period as well. This guide explains how, as a client, to plan and manage UAT.
Last updated: October 2026
What is acceptance testing and why does it matter?
Before software is delivered it passes through several layers of testing:
| Test type | Who does it? | What does it check? |
|---|---|---|
| Unit / integration testing | Developer/vendor | That the code's parts and components work technically |
| System testing / QA | The vendor's test team | That the system as a whole meets the requirements |
| Security and performance testing | Vendor/specialist | Vulnerabilities, speed, behaviour under load |
| Acceptance testing (UAT) | Client / real users | That the system fits your real business processes |
The difference of UAT: it asks not “was it built right?” but “was the right thing built?” A technically flawless system is useless if it does not fit your workflow. That is why UAT is the natural continuation of vendor selection and client responsibilities.
Acceptance criteria: write them up front
An acceptance criterion is the condition that must be met for a feature to count as “done.” It should be written before delivery, even together with the scope, so it does not cause arguments during acceptance.
A weak criterion: “The order screen should be usable.” A strong criterion: “A sales representative should be able to create an order for a new customer, add 5 line items and save it within 2 minutes; the order should appear in the warehouse list and an email notification should go to the customer.”
Criteria should be measurable, observable and clear: who does what and sees what result? Scope and acceptance criteria should also go into the contract as an annex; see our software contract checklist.
The UAT plan in 8 steps
1. Scope and goal
What will you test? The whole system, or the features delivered in this release? What is the success measure? (E.g. “All critical scenarios pass, no open critical/high bugs.”)
2. Team and roles
- Test coordinator: Usually the product owner; manages the plan and collects findings.
- Test users: The people who will actually use the system (sales, warehouse, accounting, manager). Have at least one person from each role.
- Vendor side: A contact who fixes bugs and answers questions.
- Set aside time for testing: If users will test alongside their daily work, make sure it is planned and protected time.
3. Test environment
- Use a test (staging) environment separate from production; don't touch live data.
- The environment should resemble production as closely as possible (version, settings, integrations).
- Use test/sandbox accounts for integrations (payments, email, ERP).
4. Test data
- Test with realistic data: different customer types, long names, special characters, empty fields, large numbers, date boundaries.
- If you will use real personal data, anonymise it or keep the test environment as protected as production; don't forget KVKK obligations. If legacy data was migrated, see our data migration guide for verification.
5. Test scenarios
Derive scenarios from workflows; instead of touring screen by screen, try end to end. (Detail below.)
6. Bug management
Collect findings in one place (a table or tracking tool): what, where, how to reproduce, severity, status. (Template below.)
7. Re-testing (regression)
After fixes, re-test the bug and its surroundings; one fix can break something else.
8. Acceptance decision
Give written acceptance based on the acceptance criteria and the status of open bugs (with a list of the bugs if conditional acceptance is needed).
How to write a test scenario
A good scenario tells a business story:
| Field | Example |
|---|---|
| Scenario name | Create an order and invoice for a new customer |
| Role | Sales representative |
| Precondition | Logged in; product list loaded |
| Steps | 1) Add a new customer 2) Create an order, select 3 products 3) Apply a discount 4) Save 5) View the invoice |
| Expected result | The order is saved with status “New”; stock decreases; an email goes to the customer; the invoice amount is correct |
| Actual result / status | (Filled in during testing: Passed / Failed) |
Scenario types to cover
- Happy path: The main flows when everything goes well.
- Invalid input and boundary cases: Missing field, wrong format, very long text, negative number, adding the same record twice.
- Exceptions and business rules: Returns, cancellations, partial shipment, out of stock, limit exceeded, discount combinations.
- Permissions and roles: Does each role see only what it should? Can an unauthorised user perform an action?
- Integrations: Email/SMS notification, payment, ERP transfer, file upload/download.
- Reports and outputs: Do the numbers match real business data? Is export correct?
- Different devices and browsers: Try the environments your users actually use (including mobile).
- Performance feel: With real data volume, do screens open in a reasonable time?
- Data accuracy: Are random samples from migrated legacy data correct?
- Rollback and error messages: When an error occurs, is the user given an understandable message? Is there no data loss?
Important: Add the exceptions of the work you actually do to the scenarios; most problems appear not in the “normal” flow but in the exception.
Bug (finding) log and prioritisation
Bug log template
- ID: A unique number
- Title: A short summary
- Role / environment: Who saw it, on which device/browser?
- Steps: How to reproduce?
- Expected / actual result
- Screenshot / video
- Severity (below)
- Status: New / Under review / Fixed / To be re-tested / Closed
Severity levels
| Level | Definition | Example | Effect on acceptance |
|---|---|---|---|
| Critical | The system does not work, or there is data/security/money risk | Orders are not saved; an unauthorised person sees data | Blocks acceptance |
| High | An important feature does not work, no workaround | The invoice amount is calculated wrongly | Generally blocks acceptance |
| Medium | The feature is partly affected, a workaround exists | Report sorting is wrong | May allow conditional acceptance with a planned fix |
| Low | Cosmetic or minor improvement | Typo, alignment | Does not block acceptance; added to the list |
An important distinction: A bug (a feature in scope does not work correctly) differs from a new request (something not in scope). New requests go through the change management process and may create extra scope/cost. Keeping this distinction clear reduces arguments. For the terms, see our software terms glossary.
How is the acceptance decision made?
Acceptance is not a “feeling;” it is a decision made according to rules set in advance. Example rules:
- All critical and high bugs have been fixed and re-tested.
- For medium bugs, a fix plan and date are written.
- All critical scenarios have passed.
- All acceptance criteria (or an agreed share) have been met.
- Required documentation, training and access (source code, accounts) have been delivered.
Decision types:
- Acceptance: The criteria are met.
- Conditional acceptance: There are small open bugs; accepted on condition that they are fixed within a set time. (The list of bugs and dates must be in writing.)
- Rejection / re-test: There are critical gaps; re-test after fixing.
Be careful: In most contracts, acceptance is tied to payment, the start of the warranty period and sometimes the transfer of liability. Don't rush; if the contract has clauses such as deemed acceptance through silence (accepted if no objection is made within a set time), follow them carefully. For details, see the contract clauses and your legal adviser.
Go-live check
After acceptance, before going live:
- Data migration is complete and verified; a rollback plan is ready
- User training has been done; a short user guide exists
- Backup and restore testing has been done
- Security basics (administrator MFA, permissions, HTTPS, security headers) are verified: our security guide
- Monitoring and alerts are set up
- Accounts and access (domain, server, source code) have been handed over to you
- Support channel and maintenance plan are clear: our maintenance and SLA guide
- There is a close-follow plan for the first days after launch
8 common UAT mistakes
- Leaving testing to the last day. If time and users aren't set aside, problems appear in production.
- Trying only the “happy path.” Exceptions and invalid input are neglected.
- Leaving out the real user. The manager says “good” from their own viewpoint; the employee doing the work doesn't see it.
- Not writing acceptance criteria up front. Afterwards everything is a matter of argument.
- Confusing a bug with a new request.
- Sending findings scattered (email, messages, verbally). They can't be tracked.
- Not re-testing fixes.
- Giving “conditional acceptance” with open items and not keeping the list in writing.
Short UAT checklist
- Acceptance criteria are written and approved
- The test team and coordinator are set; time is set aside
- A separate test environment and realistic/anonymised test data are ready
- Scenarios are derived from workflows; exceptions included
- Testing has been done for every role (including permission checks)
- Integrations have been tested
- Reports and figures have been verified
- Findings are tracked in one place with severity levels
- Fixes have been re-tested
- The acceptance decision has been given in writing
- The pre-launch checklist is complete
Delivery and acceptance with Aktaş Digital
In our projects we plan delivery with acceptance criteria: we write scope and acceptance conditions at the start, show regularly working versions, provide a test environment, track findings and re-test the fixes together. After acceptance we stay with you through a support and maintenance plan. We apply this method in business software such as web applications, CRM, ERP and inventory tracking systems. To describe your project, you can use our quote form. For the process from start to finish, also see our MVP roadmap.
Frequently Asked Questions
Who should do UAT, the vendor or the client?
Acceptance testing is done by the client side, because only you know fitness for the business. The vendor prepares the test environment, answers questions and fixes bugs. The vendor's own internal tests are done separately.
How long does UAT take?
It depends on the system's size and the number of scenarios; it can take from a few days to a few weeks. Plan the time at the start and protect users' time; also allow for bug-fix and re-test rounds.
I have no technical knowledge; can I test?
Yes. Acceptance testing is not a technical test but a business test: you do your real work in the system and see whether the results are right. For a technical review (security, code quality), get support from an independent expert if needed.
Can I stop payment if bugs appear?
That depends on the payment and acceptance provisions in your contract. If payments are tied to deliveries and acceptance, you have a right to object to a delivery that does not meet the criteria. For legal details, consult your legal adviser.
Will bugs still appear after going live?
Yes; no test covers every case. That is why the warranty period, support channel and post-launch monitoring matter. A good UAT greatly reduces the risk but does not eliminate it.
Is automated testing the same as UAT?
No. Automated tests quickly and repeatedly check the code's technical correctness; UAT is real users confirming fitness for the business. The two complement each other.
Conclusion
Acceptance testing is the last and most valuable assurance before saying “yes, this does our job” to the software. Write the acceptance criteria up front, try real scenarios (with their exceptions) with real users, prioritise and track findings, re-test fixes and give acceptance in writing. The first thing you can do today: write your project's three most critical workflows as end-to-end scenarios and set measurable acceptance criteria for them.
