northdan.
Vezi pagina în română

IT Glossary

What is UAT (user acceptance testing)?

The final testing stage, where the future users check the software against real scenarios and decide whether it is ready to launch.

The last word before a software launch does not belong to the developers; it belongs to the people who will use the thing every day. That is the essence of user acceptance testing. Once the technical team has confirmed the application behaves correctly, real users from your company put it to work on concrete business scenarios: the bookkeeper issues an invoice from start to finish, the warehouse manager books in a delivery, the salesperson walks through a complete order. The purpose is not to find technical bugs but mismatches with reality — missing fields, flows that do not match how the company actually works, special cases nobody thought of when the specification was written. Why it matters commercially: a problem caught here costs one correction, while the same problem discovered after launch costs wrongly issued invoices, frustrated employees who quietly refuse the new system, and fixes improvised on live data. The formal acceptance signed at the end protects both sides, because you know what you received and on which criteria payment was approved. It is also the cheapest change management available, since the people who tested the system arrive at launch day already knowing it and already invested in it.

Let’s talk about your project

Message us on WhatsApp or send an email — you talk directly to a developer.

office@northdan.com · +40 752 070 247

Why it matters for your business

Problems appear before launch, not after

Mismatches with real processes surface in a test environment where correction is cheap, rather than on live data with customers and invoices already affected.

Acceptance on clear criteria, not impressions

Scenarios agreed in advance make the conversation with the supplier objective: each one passes or fails, and the final payment attaches to the result.

Easier adoption across the team

Employees involved in testing already know the system at launch and shaped it with their observations, so resistance to the change drops visibly.

Frequently asked questions

Who should perform acceptance testing inside a company?

The real end users, from every role the system touches: the accountant tests invoicing, the warehouse manager tests stock, the manager tests reports. Do not delegate the whole exercise to the IT contact or to one willing volunteer — each role knows its own special cases, and those special cases are precisely where the expensive problems are hiding.

How does acceptance testing differ from the development team’s own testing?

The development team, including through automation, verifies that the software works correctly in technical terms: no errors, behaviour matching the specification. Acceptance testing checks something else entirely — whether the specification itself matches the real need of the business. A system can pass every technical test impeccably and still fail acceptance, which is not a contradiction but exactly the point of holding the stage.

How long does acceptance testing take, and what if we find problems?

For a typical company project, one to three weeks with scenarios prepared in advance. Findings get classified: blockers are corrected and retested before acceptance, while minor items can be accepted with an agreed deadline for resolution. What matters is that everything is recorded in writing, including the accepted minor items, because the memory of a verbal agreement fades exactly when an invoice is disputed.