SIT (system integration testing) checks that separate systems work together correctly. UAT (user acceptance testing) checks that the finished product does what the business needs. SIT comes first and is run by developers or testers, and UAT comes last and is run by the people who will own or use the product.

Put simply, SIT tests the connections and UAT tests the outcome. You can pass one and fail the other.

SIT vs UAT at a glance

	SIT	UAT
Full name	System integration testing	User acceptance testing
Question it answers	Do the systems exchange data correctly?	Does this do what we need?
Who runs it	Developers, QA, integration specialists	Client staff, end users, product owner
When it happens	After component and system testing	Last, before release
Tested against	Technical specs, API contracts, data mappings	Business requirements and real tasks
Where it runs	Integration environment with sandboxes	A UAT environment close to production
Test data	Built to hit edge cases	Realistic business data
Typical failure	Order sent to the warehouse without VAT	Staff cannot tell which orders are for collection
Tools	API clients, logs, automated tests	Scenarios, a feedback tool, a sign-off form
Result	Defects fixed, ready for UAT	A go or no-go decision

What does SIT testing mean?

SIT stands for system integration testing, so "SIT testing" is technically a repeat, but it is how most people search for it. It means testing the points where one system hands off to another.

Websites rarely stand alone. On a typical project, SIT covers the connections to:

Payment gateways
CRMs and marketing platforms
Stock, warehouse or ERP systems
Shipping and tax services
Single sign-on
Transactional email

SIT checks that data goes across in the right format, arrives complete and is handled correctly when something goes wrong. Failure handling is where most of the value is. Testers deliberately send bad data, simulate timeouts and repeat messages to see what the receiving system does.

There are a few common ways to approach it:

Big bang. Connect everything, then test. Simple to organise, but faults are hard to trace.
Incremental. Add one connection at a time and test as you go. Slower to start, much easier to debug.
Top-down or bottom-up. Incremental approaches that start from the user-facing layer or the underlying services, using stand-ins for whatever is not ready yet.

For most website builds, incremental is the sensible default, because each integration usually comes from a different supplier and arrives at a different time.

SIT and UAT: why you need both

SIT and UAT cover different risks. SIT finds faults that are invisible to a person using the site, such as a duplicate message or a rounding error between two systems. UAT finds faults that are invisible to the technical checks, such as a process that works perfectly but does not suit the people using it.

They also depend on each other. A completed SIT should be one of the entry criteria for UAT, and our guide to user acceptance testing shows where that fits. Testers who hit integration faults during UAT cannot tell what caused them and quickly lose confidence in the whole build.

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Worked example: the same feature at both stages

Take a fictional online bike shop. When a customer pays, the website takes payment through a gateway, sends the order to a warehouse system, reduces stock and sends a confirmation email.

What SIT checks

Payment providers publish test details for this stage. Stripe's testing documentation, for example, gives card numbers that simulate approved and declined payments in a sandbox, so nobody needs a real card.

SIT test	Input	Expected result
Payment success message	Approved test card	Order marked paid and one transaction stored
Duplicate message	Same payment event sent twice	Order updated once, no second transaction
Order export	Order with three lines and a discount	Warehouse receives three lines with correct product codes and VAT
Warehouse outage	Warehouse API returns a 503 error	Order queued, retried automatically, alert raised
Stock update	Last item in stock is sold	Stock reaches zero and the product shows as sold out
Email trigger	Order marked paid	One confirmation email queued

What UAT checks

Now the same feature goes to the people who will use it. They are not looking at messages or status codes.

UAT scenario	Tester	A pass means
Buy a bike as a guest on your phone	Customer service adviser	Clear steps, payment works, confirmation makes sense
Find yesterday's order and change the delivery date	Warehouse coordinator	Done without asking a developer
A customer calls to say their card was declined	Customer service adviser	They can see what happened and advise the customer
Read the order confirmation email	Marketing manager	Delivery date, returns information and tone are correct

What each one catches

Here are two invented bugs that show the difference.

Caught by SIT. The gateway resends a payment event after a slow response, and the site creates a second order. A UAT tester would almost never see this, because it depends on timing. A SIT test that sends the same event twice finds it immediately.

Caught by UAT. Orders reach the warehouse system perfectly, with every field correct. But the click and collect flag sits in a column the warehouse team's screen does not show, so collection orders get packed for delivery. Every technical check passes and the business still cannot use it.

Common mistakes

Skipping SIT because it is only a plugin. A plugin still sends data to another system, and that handoff can fail in ways the plugin's author never tested against your setup.

Running UAT against stand-ins. Mocks are fine in SIT. UAT should use real sandbox connections, otherwise testers are approving something that does not yet exist.

Overlapping the two to save time. When schedules slip it is tempting to start UAT while SIT is still going. Testers then report failures caused by half-finished integrations, and the team spends triage working out which reports are real.

Reusing SIT data for UAT. Records named "Test Test" with a price of 0.01 are fine for SIT. Testers need data that looks like the real business or they stop reading it properly.

Forgetting to retest connections after UAT fixes. A change to the checkout made during UAT can break the order export. Run a regression test over the integrations before launch.

Can you combine SIT and UAT on a small project?

You can combine the schedule, but keep the responsibilities apart. On a small site with one or two integrations, a developer can run through the connections in an afternoon, then hand over to the client. The order still matters: integration checks first, UAT second.

A quick smoke test of the site before you invite testers catches the most obvious integration faults. For the UAT part, give testers a simple way to report problems. Website UAT software such as QualityHive, which is our product, lets them click the problem on the page instead of writing it up in an email.

Revolutionise your QA processes

Frequently asked questions

What does SIT stand for in testing?

SIT stands for system integration testing. It checks that separate systems or components exchange data correctly and handle errors properly when they are connected together.

Does SIT come before UAT?

Yes. SIT comes first because UAT testers need a product whose connections already work. A completed SIT is normally an entry criterion for UAT.

Who is responsible for SIT?

Developers, QA engineers or integration specialists run it, often with help from the suppliers of the connected systems. Business users are not usually involved.

Is SIT the same as system testing?

No. System testing checks one complete system against its specification. SIT checks how that system behaves when connected to others. On small projects the two often happen together.

Can UAT start before SIT is finished?

It can, but it usually costs more time than it saves. If a connection is unfinished, mark any scenarios that depend on it as blocked and do not ask testers to run them until SIT is complete.