SIT vs UAT: The Difference, Who Runs Each, and When
Last updated: November 6, 2026
SIT (system integration testing) checks that your system and the systems it connects to work together. UAT (user acceptance testing) checks that the people who will use it accept it. QA engineers and developers run SIT first; clients, business users, or end users run UAT last, before release.
The ISTQB glossary defines system integration testing as "a test level that focuses on the integration of systems", and user acceptance testing as "a type of acceptance testing performed to determine if intended users accept the system". In plain terms, SIT asks whether the connections work. UAT asks whether this is what people need.
This guide compares the two, explains why guides disagree on where SIT belongs, and shows what each one looks like on a real website project. For UAT on its own, see what user acceptance testing means.
SIT vs UAT at a Glance
| SIT | UAT | |
|---|---|---|
| Question it answers | Do the connected systems work together? | Will the intended users accept this? |
| Who runs it | QA engineers and developers | Clients, business users, or end users |
| When | After system testing, before UAT | Last test phase before release |
| What it tests | Data flow, APIs, third-party connections | Real tasks and business rules |
| Environment | Integration or staging, with test accounts for connected services | Staging that mirrors production |
| Test data | Prepared data that exercises each connection | Realistic data the users recognize |
| Typical finding | An order never reaches the CRM | The order form asks for the wrong details |
| Done when | No blocking integration defect is open | Users or the client sign off |
Does SIT Come Before UAT?
Yes. SIT comes first, because there is little point asking people to accept a product whose connections are still broken. UAT is the last check before release.
Where SIT sits relative to system testing is less settled. GeeksforGeeks places it after unit testing and before system testing. Marker.io places it after system testing and before UAT. Both are describing something real, because integration testing covers two levels. The ISTQB Foundation syllabus describes five test levels, in this order:
- Component testing: one part on its own.
- Component integration testing: the parts of one system working together.
- System testing: the system as a whole against its specified requirements.
- System integration testing: that system working with other systems.
- Acceptance testing: deciding whether to accept the system, which is where UAT belongs.
So a guide that puts integration testing before system testing is describing the second level, and one that puts it after is describing the fourth. Many teams say "SIT" for both, so ask which one a test plan means. The syllabus also notes that test levels can overlap in time, so read this as an order of concerns rather than a strict calendar.
What SIT and UAT Look Like on a Website Project
The difference is easier to see on a website than in the abstract. These rows are illustrations, not a real client's test plan.
| Part of the site | SIT checks | UAT checks |
|---|---|---|
| Contact form | The submission reaches the CRM with every field mapped | The fields ask what sales needs, and the thank-you message reads right |
| Checkout | The payment provider takes a test card and the order reaches fulfillment | A buyer can finish the purchase, and shipping and tax match the client's rules |
| Analytics | Events fire and arrive in the analytics account | The client can find the report they were promised |
| Single sign-on | The identity provider returns the right account and role | Each kind of user sees what they should after logging in |
| Content from a CMS | Entries publish through the API to the right page | Editors can make their usual updates without help |
Can SIT Pass and UAT Fail?
Yes, in both directions. SIT can pass while UAT fails: the CRM receives every field, and the form still asks the wrong questions. UAT can pass while an integration problem stays hidden: a client accepts the checkout on test data, and the live payment confirmation fails on launch day. That is why skipping either one leaves a gap the other cannot see.
Entry and Exit Criteria for SIT and UAT
In a sequential project, the exit criteria of one level are often part of the entry criteria for the next, so finishing SIT cleanly is what lets UAT start. These are common starting points; adjust them to your project.
| SIT | UAT | |
|---|---|---|
| Start when | System testing has passed for this build, test accounts exist for each connected service, and the interfaces are agreed | SIT's exit criteria are met, acceptance criteria are agreed, staging mirrors production, and testers are named and briefed |
| Finish when | Planned integration cases have run, no blocking defect is open, and known issues are logged | Key tasks pass, blockers are fixed and re-tested, and sign-off is in writing |
| Output | Test report and defect log | Feedback list and written sign-off |
For UAT, the criteria carry the most weight, because they decide what "accepted" means. See these UAT acceptance criteria examples for UI and design work.
Who Should Run Each One on a Small Team
The ISTQB syllabus gives a typical split: developers run component and component integration testing, the test team runs system and system integration testing, and business representatives run acceptance testing.
On a small team, the developer who built an integration often runs SIT too, and that can work. UAT is different. The people who built the site know how it is supposed to behave, so they will not run into what a client runs into. Keep UAT with the client or the people who will use the site, even if your whole team is one developer.
How to Collect UAT Feedback
UAT often slows down when feedback arrives as scattered emails and screenshots. Ask for it in one place, with a clear request that names what to check and by when.
In OverlayQA, you create a client link for the page and add the client's email. They open it in any browser, including on a phone, with no account, and each comment becomes an issue in your project with the screenshot attached.
There is no approval step on each issue, so ask for final sign-off in writing. OverlayQA does not run SIT: it records what people see on the page and does not test the connections between systems. For other options, see the best UAT testing tools.
Frequently Asked Questions
What is the difference between SIT and UAT?
SIT checks that your system and the systems it connects to work together. UAT checks that the people who will use it accept it. SIT is technical and run by QA engineers and developers. UAT is run by clients, business users, or end users.
Does SIT come before UAT?
Yes. SIT comes first, so the people running UAT are not stopped by broken connections. UAT is the last test phase before release.
Who performs SIT and UAT?
QA engineers and developers usually run SIT. Clients, business users, or end users run UAT. Keep UAT away from the people who built the product, because they already know how it is supposed to work.
What is an example of SIT?
On an online store, SIT checks that the payment provider takes a test card, the order reaches the fulfillment system, and the confirmation email goes out. Each check crosses a connection between two systems.
Can SIT and UAT share an environment?
They can on a small project, as long as the build stays stable while UAT runs. If developers are still fixing integration defects on staging, UAT testers will hit moving targets, so finish SIT first or give UAT its own copy.
Is UAT the same as system testing?
No. System testing checks that the whole system meets its specified requirements, and the test team runs it. UAT checks whether the intended users accept it. A product can meet its written requirements and still fail UAT, because the requirements themselves were wrong.
Do you need both SIT and UAT?
Usually. If a site connects to nothing beyond its hosting, SIT shrinks to a few checks, but most sites have forms, analytics, or payments to test. UAT is worth keeping on any client project, because it is where the client confirms the work.
Run UAT feedback from one link. With OverlayQA, clients comment on the page with no account, and each comment becomes a tracked issue with the screenshot attached.