User Acceptance Testing (UAT): Making Sure the App Is Ready Before Launch

There is a moment well known to anyone who has waited for a software project to finish: the development team declares the app done, the demo runs smoothly, and everyone prepares to launch. Then a week after real use, a list of complaints starts arriving. Reports do not match the finance team's habits, the approval flow does not fit how work happens in the field, and some rare but important cases turn out not to be handled.

The gap between "meets the specification" and "meets the need" is often wider than expected. Developers test that the app works as designed. Only users can answer whether the design really fits the way they work. This is where user acceptance testing, or UAT, takes its role: the last stage before launch where real users try the app with real scenarios and declare it fit or not.

This article explains UAT for business owners and project managers, not professional testers. We cover how it differs from other testing, how to plan it, write scenarios, choose testers, record and prioritise findings, and determine when the app may be launched. We use no invented figures about defect counts or ideal duration; every project is different. What we offer is a practical framework you can adapt.

Summary

• UAT is testing by real users against real work scenarios, to confirm the app meets business needs, not just technical specifications
• Plan UAT from the start of the project: set the timing, testers, test environment, and pass criteria before development finishes
• Write scenarios based on daily work, including unusual cases and mistakes, not only the perfect path
• Record every finding in a structured way, prioritise by business impact, and decide which must be fixed before launch
• Set agreed launch criteria and prepare a plan in case problems occur after going live

What UAT is and how it differs from other testing

Software development involves several layers of testing with different purposes. Unit testing checks small pieces of code in isolation. Integration testing checks whether those pieces work together. System testing by a test team confirms the whole app works according to specification. All of this is generally done by technical teams and answers the question, "Did we build what was planned?"

UAT answers a different question: "Does what we built actually get our work done?" The testers are not technical people but business users: cashiers, warehouse staff, finance admins, sales managers. They run the app with data and scenarios that resemble their daily work, then judge whether the flow makes sense, the results are correct, and the app is fit for use.

This difference matters because a specification can be wrong or incomplete. A feature built exactly according to the requirements document can still be useless if that document missed one important working step. Only users who experience the work every day will notice, "Oh, here we usually also need to record this."

So UAT is not a signing formality at the end of the project. It is the last safety net between a misunderstanding and real operations. Shortening it to meet a schedule almost always ends in greater cost after launch, when fixes must be made while the business is running.

Planning UAT from the start of the project

Good UAT does not start when the app is finished, but when the project is planned. If it is only thought of at the end, there is usually little time left, testers are unavailable, and the pressure to launch quickly leads to findings being ignored.

The first thing to agree on is time. Allocate a sufficient UAT period in the schedule, including time to fix findings and retest. Many project schedules fail because UAT is assumed to take one or two days, when the cycle of test, fix, and retest usually repeats several times. Leave room for that from the start.

Second, decide who is involved and make sure they are actually given time. Testers are employees with daily jobs. If they are asked to test while still doing all their tasks, UAT quality will be poor. Get managers' support so testers have dedicated time. Third, decide the test environment: a copy of the app separate from the live system, containing realistic test data, so experiments do not damage business data.

Fourth, decide the pass criteria early. What must be met for the app to be declared ready? For example all core scenarios run without severe defects, no defect blocks the main work, and key stakeholders approve. Agreement at the start prevents arguments at the end when pressure is high.

Roles and responsibilities

Decide who coordinates UAT, usually a project manager from the business side. Also decide who receives finding reports on the developer side, who decides priorities, and who has the authority to declare a pass. One clear person in charge prevents findings falling between two parties who each assume the other is handling it.

Writing useful test scenarios

A test scenario is a series of steps that imitates real work, together with the expected results. The quality of scenarios determines the quality of UAT. Good scenarios start from business processes, not from a list of features.

Start by listing the main jobs users will do with this app, for example creating an order, receiving goods, closing the daily cash, requesting leave, or approving a purchase. For each job, write the steps from start to finish, the data used, and the expected results, such as stock decreasing by a certain amount or a report showing a particular figure.

Do not test only the perfect path. Real work is full of events that are not smooth: a customer cancels midway, partial payment, returned goods, mistyped data, or a rejected approval. Add scenarios for unusual cases and errors, because that is where many hidden problems lie.

1. 01Use the language and terms users use every day, not the technical terms of the development team
2. 02Write steps detailed enough that someone trying for the first time can follow them
3. 03Include realistic test data, including difficult examples such as long names, large numbers, and special characters
4. 04State expected results that can be clearly checked, not just "works well"
5. 05Include cross role scenarios, for example an order created by a cashier, approved by a manager, then reported to finance
6. 06Include scenarios for reports, because reports are often the main reason the app was built

Test with near real data and situations

An app that looks smooth with five rows of sample data can slow down or become confusing with thousands of real records. If possible, load test data close to the volume and variety of real data, for example a partial, anonymised migration of old data. Also test on the devices and connections users actually use, including the simplest. Testing on a developer's fast laptop does not represent a shop with an old tablet and weak signal.

Choosing and preparing testers

The best testers are the people who will use the app every day, because they understand the work best. Choose representatives from each main role, including critical and sceptical ones. Enthusiastic testers help, but testers who are careful and dare to say "this does not fit" are far more valuable to the app's quality.

The number does not need to be large. A few people per role are usually enough to find most workflow problems. More important is diversity: experienced users and beginners, fast and slow people, because each reveals different problems.

Prepare testers before starting. Explain the purpose of UAT, what is expected of them, and how to record findings. Give a short training so they know the app's basics, but do not guide them so much that you cover up usability problems that should be visible. If testers get stuck and need to ask too often, that itself is a valuable finding about the app's clarity.

Running UAT and recording findings

While UAT runs, create a consistent recording habit. Each finding should be recorded in the same format so it is easy to follow up. It includes a short description of the problem, steps to reproduce it, the expected result and what actually happened, a screenshot where helpful, and who found it.

Avoid vague notes such as "report is wrong". A good note reads like: "On the daily sales report, the total for a particular date differs from the sum of the transactions in the list; with certain test data the total shows this much when it should be that much." These details save developers a lot of time and cut back and forth questions.

Collect all findings in one place, not scattered across private messages and group chats. A shared list, even just a spreadsheet, makes it easy to track the status of each finding: new, being fixed, ready for retest, or done. It also prevents the same finding being reported repeatedly and gives everyone a clear picture of progress.

Review findings together regularly, for example every day or two while UAT runs. A short meeting between business representatives and developers clarifies ambiguous findings, agrees priorities, and keeps the rhythm of fixes going.

Prioritising findings

Not all findings are equally important, and not all must be fixed before launch. Grouping by business impact helps make rational decisions under time pressure.

• Critical: blocks main work or causes wrong data, financial loss, or a security risk; must be fixed before launch
• Important: work can still be done but in an awkward way or with less accurate results; should be fixed before launch, or have an agreed workaround
• Minor: comfort or appearance issues that do not affect work results; can be scheduled after launch
• Suggestion: improvement ideas that are really outside the original scope; noted for the next phase, not to be added at the last minute

Note the difference between a defect and a change of requirements. A defect means the app does not work as agreed. A change of requirements means users realise they want something different from what was agreed. Both are legitimate and valuable, but handled differently: defects are fixed within project scope, while requirement changes are assessed for impact on time and cost, then decided together. Mixing the two is one of the main sources of project bloat.

Avoiding the "oh well, later" trap

Near the deadline, the biggest temptation is to postpone all findings on the grounds that they will be fixed after launch. Some can be, but too much repair debt makes users lose trust from day one. The first impression users get of a new app strongly affects their acceptance. If day one is full of problems that were already found, they will be hard to win back.

Deciding when the app is fit to launch

The decision to launch should be based on agreed criteria, not feelings or pressure. Review the pass criteria set at the start and check them one by one. Did all core scenarios pass? Are there no critical findings left? Do the remaining important findings have an approved workaround? Do representatives of each main role say they are ready?

Document the decision. Written approval from key stakeholders is not mere bureaucracy; it ensures everyone understands the app's condition at launch, including findings accepted as risks. It also avoids misunderstandings later about what had and had not been agreed.

If the criteria are not met, having the courage to postpone launch is often cheaper than launching an app that is not ready. A rushed launch that must then be pulled back or fixed in chaos costs far more, in both money and trust. Also consider a phased launch, for example starting with one branch or one team, to limit the impact if problems appear.

After launch: keeping the learning cycle going

UAT does not mean testing ends. After launch, set up an intensive support period in which the development team and business representatives stand by to handle problems that appear. Provide an easy reporting route for users and respond quickly, because fast responses in the early days strongly shape acceptance.

Prepare a rollback plan, a way to return to the old way of working or the previous version if something serious happens. This plan is rarely used, but its existence makes the decision to launch far calmer. Also make sure data entered during the early period is not lost if you have to roll back.

Gather lessons from the UAT process for the next project: which scenarios revealed the most problems, what was missed until after launch, and how cooperation between business and developers can improve. From project to project, this process becomes lighter and more effective.

Common mistakes in UAT

Several mistakes recur across many projects. Scheduling UAT too briefly and too close to the launch deadline is the most frequent. Using developers or people who do not know the work as testers in place of real users is another. Testing only the perfect path, using too little and too tidy test data, and not recording findings in a structured way are also very common.

Another mistake is not involving decision makers until the end, so approval comes late and with large changes of request. Involve key stakeholders from the start, including in reviews of UAT progress, so there are no last minute surprises.

Practical steps to run UAT

1. 01Put UAT into the project schedule from the start, including time for fixes and retesting
2. 02Appoint a coordinator, testers from each role, a test environment, and pass criteria
3. 03Write scenarios from real work, including unusual cases, errors, and reports
4. 04Prepare realistic test data and give testers dedicated time and a short briefing
5. 05Record all findings in one shared list with a uniform format and review it regularly
6. 06Prioritise by impact, decide on launch according to the criteria, and prepare a rollback plan

Conclusion

UAT is a small investment that protects a big one. An app built at high cost can fail to be accepted just because of a few things that do not fit real working practice, and those things can almost always be found before launch if real users are given the chance to try. With good planning, realistic scenarios, and decisions based on criteria, UAT turns launch from a gamble into a measured step.

If you are working on a software or new system project, do not wait for the app to be finished before thinking about UAT. Plan from the start, involve the right people, and allow enough time. An app that is well received on day one is the result of preparation done long before.