Igor
UAT is the business owner deciding the release does what the business needs. QA (and system testing) check that the software was built to the spec. Beta testing puts a build in front of real users before everyone gets it. Mixing the four is how a team "does UAT" with only QA engineers on staging, or calls a beta a sign-off. The existing UAT guide is the how-to; this post is the definitions, so the round and the tools match the job.
Four definitions
| Who | Question | Where | Exit | |
|---|---|---|---|---|
| QA (functional / system) | Testers, often professional | Does it match the spec and not fall over? | Test or staging | Planned cases run, defects known |
| System testing | QA | Do the parts work together (payments, email, roles)? | An environment with real integrations | End-to-end paths pass |
| UAT | People who own the business process | Can we do our actual work and accept this release? | Staging that looks like production | Named sign-off, open defects listed |
| Beta | A slice of real users | What happens in the wild? | Production or production-like, limited audience | A time box, not a legal acceptance |
System testing is a kind of QA. It is called out because teams say "UAT" when they mean "we finally tested checkout against the real payment gateway". That is still QA. The business has not accepted anything.
How they get mixed
- QA runs UAT. They will pass the spec and miss that finance still calls the field "client" not "account". UAT needs the people who do the job.
- UAT is a beta. Real customers on production find issues you should have found on staging, and there is no sign-off record, only a Slack vibe.
- Beta is skipped and called UAT. Fine for an internal tool. Reckless for a consumer app where device and network diversity matter.
- Sign-off is a tester's pass rate. Testers do not accept the business risk. See who should sign off.
Tools follow the job
Case management (TestRail, Xray) serves QA. Capture widgets serve whoever is looking at the build: QA and UAT both need defects with evidence. Sign-off is a record, sometimes a product like Bugzy, often a document. Beta needs analytics, crash reporting and a way for users to report without a test script. SnagRelay is capture for QA and UAT. It is not a case tool, not sign-off, not a beta analytics suite. That limit is on the UAT page.
A sane order on one release
- QA and system testing on staging, including real integrations.
- Fix or defer the defects; write the known list.
- UAT with business testers on the same kind of staging, scenarios not scripts; defects captured; exit criteria applied.
- Sign-off by the named owner.
- If the product needs it, a beta in production with a subset of users, crash tool on, a report button for what testers will not see.
Skipping 1 and jumping to 3 wastes business people's time on broken builds. Skipping 3 and shipping after QA is how "technically correct" software still fails the process.
Where a report button sits
On the QA and UAT staging site (widget) or via the Chrome extension behind a login. Testers point at what is wrong. Developers get the element, errors and requests. The round still needs a plan and a sign-off you write down. For non-technical UAT testers, see how to run that round.
FAQ
What is the difference between UAT and QA?
QA checks the build against the spec. UAT is the business accepting that they can do their work with it. Different people, different question, different exit.
Is system testing the same as UAT?
No. System testing is QA of the integrated system. UAT is acceptance by the people who own the process.
Is beta testing a form of UAT?
No. Beta is real users, often in production, time-boxed. UAT is a named acceptance of a release, usually on staging, before go-live.
Can the same tool be used for QA and UAT?
A defect-capture tool can. A sign-off tool and a test-case tool are separate. Do not expect one widget to be all three.