SIT Testing: Where Two Working Systems Break Each Other

TL;DR

• SIT testing, or system integration testing, verifies that separate systems exchange data correctly across their real interfaces rather than against mocks of each other.
• The defect class is invisible to unit and component tests, since both sides pass in isolation while disagreeing about units, formats, timing, or error semantics.
• Five interface failures cover most of the risk, and mismatched error contracts reach production more often than the other four combined.
• Autosana runs intent-based flows across real iOS, Android, and web devices against live integrated environments, so cross-system failures surface before release.

An order service returns a total in paise. A billing service reads that number as rupees. Both services pass every test they own, because each tests against a mock of the other, and both mocks encode the same wrong assumption.

That defect survives unit testing, component testing, and contract tests written from a stale specification. SIT testing wires the real systems together and watches what crosses the boundary.

This guide covers what SIT testing verifies, how it differs from the stages either side, the interface failures worth targeting, how to sequence the work, and what a mobile client adds.

What Is SIT Testing?

SIT testing stands for system integration testing. It verifies that two or more independently built systems work together across their actual interfaces.

The ISTQB Foundation Level syllabus separates component integration testing, covering modules inside one system, from system integration testing, covering whole systems talking to each other. ISO/IEC/IEEE 29119-2 places it inside the dynamic test process.

Three properties define it. The systems under test are built by different teams or vendors. The interfaces are real rather than stubbed. The defects it finds live in the gaps between systems rather than inside any one of them.

That third property is why the stage exists. Each team can ship correct software and the product can still be broken.

How Does SIT Testing Differ From System Testing and UAT?

Order matters. System testing confirms each piece works. SIT testing confirms the pieces agree. UAT confirms the result is what the business asked for.

Teams jumping from system testing to UAT push interface defects into a stage owned by business users, who report them as "the app is broken" rather than as a units mismatch between two services.

Which Interface Failures Should SIT Testing Target?

Five categories account for most of what SIT testing finds.

Units and scale. The paise and rupees example above. Also seconds against milliseconds, kilobytes against bytes, and percentages expressed as 0.1 on one side and 10 on the other.

Format and encoding. Date formats differing between ISO 8601 and a regional convention. Character encoding mangling names with diacritics. Decimal separators flipping between locales.

Null and optional semantics. One system treats a missing field as zero, the other treats it as unknown and refuses the record. Both behaviours are defensible, and the disagreement is the defect.

Timing and ordering. A webhook arriving before the record it references has committed. Two updates applied out of sequence. Retry logic producing duplicates where the first attempt actually succeeded.

Error contracts. One system returns HTTP 200 with an error body. The other checks only the status code and treats the failure as success. This one reaches production more often than the rest combined.

Design cases around these five rather than re-running happy paths system testing already covered.

Which Interface Should You Test First?

Sequencing matters because integration environments are scarce and expensive to hold.

Rank interfaces by two factors: what crosses them, and how recently either side changed.

Interfaces carrying money or identity go first. A units mismatch on a payment amount costs refunds; the same mismatch on an analytics event costs a dashboard correction.

Interfaces where either side deployed this week go second. A contract that held last month says little after the other team shipped.

Interfaces with no written contract go third, because testing them is partly discovery and will take longer than estimated.

Everything else runs on a schedule rather than per release. API testing at the contract layer covers these cheaply between full SIT cycles.

How Do You Run SIT Testing?

Start by drawing the integration map. List every system in scope, every interface between them, and the direction data flows. Interfaces absent from that map receive zero coverage, so the map is the test plan.

Agree the contract per interface before testing. Field names, types, units, required against optional, error shapes, and timeout behaviour. Where a written contract is missing, SIT testing becomes discovery, which is slower and more valuable.

Provision a shared environment holding every system at a compatible version. Version skew is its own defect class, since service A tested against service B version 4 says little about B version 5. Record the version matrix alongside results, and keep environments configuration explicit per run.

Seed data crossing boundaries. A customer record created in one system and consumed by three others exercises the real path. Data created directly in each system independently exercises nothing.

Run API-level checks first, since they localise failures faster. A failing API call names the interface. A failing end-to-end journey names only the journey. Martin Fowler's test pyramid reasoning holds across the boundary too: push verification as low as the interface allows. Our suites and flows API supports triggering that layer programmatically.

Then run the end-to-end journeys. End-to-end suites crossing all systems catch the timing and ordering failures single-interface checks miss.

How Do You Manage Test Data Across Systems?

This is the practical problem that sinks more SIT cycles than any defect.

A customer existing in the CRM, absent from billing, and present with a different identifier in fulfilment produces test failures describing data rather than code. Teams then spend the cycle debugging their own fixtures.

Three approaches, in order of reliability.

Seed from one source and propagate through the real interfaces. Slower to set up and the only approach that exercises the integration while creating the data.

Seed each system independently from a shared fixture definition, with identifiers agreed in advance. Faster, and it leaves the creation path untested.

Snapshot and restore the whole environment between runs. Expensive, and the only approach giving genuinely repeatable results where systems hold state.

Whichever you choose, write down which identifiers are canonical across systems. Most cross-system data problems reduce to two systems disagreeing about which field is the key.

Who Owns a Cross-System Defect?

Ownership ambiguity is why integration defects sit longer than any other class.

Log the defect against the interface rather than against a system. An issue filed as "billing is broken" starts an argument. One filed as "order-to-billing interface disagrees on currency unit" starts a fix.

Name an integration owner per interface before the cycle starts. That person holds the contract and routes the defect, which removes the round of negotiation that otherwise precedes every assignment.

Where two teams disagree about which side is wrong, the written contract decides. Where no contract exists, that absence is the defect, and writing one is the fix.

What Changes in SIT Testing With a Mobile Client?

Mobile at the end of an integration chain adds four concerns.

The client caches. A corrected value from a backend fix can sit behind a stale cache on device, so cases need an explicit cache state: cold install, warm cache, and post-invalidation.

Connectivity interrupts transactions mid-flight. A payment confirmed server-side while the client lost signal produces a user who was charged and sees failure. That is an integration defect appearing only when you test the interrupt.

Version skew widens. Backends update tgether while mobile clients update when users allow it, so a current backend serves app versions many releases old. SIT scope should name the oldest client version still supported.

Push and webhook paths need their own cases. A webhook landing before the client has refreshed is the mobile form of the ordering problem above. Mobile app testing covering only in-app actions misses these entirely.

Which SIT Testing Checks Should Be Automated?

Automate the contract checks. Field presence, types, units, and error shapes are deterministic and worth running on every build of either side.

Automate the cross-system journeys carrying money or data integrity. Order to payment to fulfilment to notification earns the setup cost, since manual execution of that chain is slow and gets skipped under deadline.

Keep manual the first pass against a brand new interface, where the contract is still being discovered and the value sits in the conversation rather than the assertion.

Run regression suites across the integration boundary whenever either side deploys. Our flows and suites organise this by boundary rather than by system, which keeps results readable when a failure spans two owners.

How Autosana Fits

We work at the end of the integration chain, where a mobile or web client consumes everything upstream.

Our flows describe what the user does, so a cross-system journey reads as one test rather than four stitched together. A failure arrives with video showing the exact step where the systems disagreed.

We run on real iOS and Android devices against whichever backend your environments configuration targets, covering the cache, connectivity, and version-skew cases above.

Our suites and flows API triggers runs from your own orchestration, so SIT testing fires when either side of an interface deploys rather than on a fixed schedule.

Results link to issues with the failing step attached, which turns a cross-team defect into something assignable.

Conclusion

Draw your integration map and count the interfaces. Then count how many have a written contract covering units, null semantics, and error shape.

The gap between those two numbers is your SIT testing backlog, and it is usually larger than expected. Start with the interfaces carrying money, since a units mismatch there becomes a refund queue.

Then test the error contract on each one. A system returning HTTP 200 with a failure body, read by a system checking only the status code, is the integration defect worth writing a case for today.

FAQ

What is SIT testing?

SIT testing, or system integration testing, verifies that separate systems exchange data correctly across their real interfaces. It targets defects living between systems rather than inside any single one.

How does SIT testing differ from system testing?

System testing verifies one assembled system against its specification, usually with other systems stubbed. SIT testing wires the real systems together and verifies they agree on units, formats, timing, and error semantics.

What is the difference between SIT and UAT?

SIT testing confirms systems exchange data correctly and is owned by QA. UAT confirms the integrated result meets business requirements and is owned by business users. SIT runs first.

What defects does SIT testing catch?

Units and scale mismatches, format and encoding differences, disagreements about null and optional fields, timing and ordering problems, and mismatched error contracts such as HTTP 200 returned with a failure body.

Which interface should be tested first?

Interfaces carrying money or identity, then interfaces where either side deployed recently, then interfaces lacking a written contract. Everything else runs on a schedule rather than per release.

How do you manage test data across systems?

Seed from one source and propagate through the real interfaces where possible, since that exercises the integration while creating the data. Agree which identifiers are canonical across systems before starting.

Who owns a cross-system defect?

Name an integration owner per interface before the cycle. Log defects against the interface rather than a system, since "order-to-billing disagrees on currency unit" routes while "billing is broken" argues.

How does a mobile client change SIT testing?

It adds client caching states, connectivity interrupts mid-transaction, wider version skew because users control updates, and push or webhook delivery arriving out of order relative to client refresh.