Definition

System Integration Testing (SIT)

System Integration Testing (SIT) checks that separately built systems, services and third-party components work together correctly once they are connected.

Full Definition

System Integration Testing (SIT) verifies the connections between systems: the data that flows between your application and a payment provider, an ERP, a CRM, an identity provider or your own microservices. Each system may pass its own tests and still fail together, because of mismatched data formats, wrong field mappings, timeouts, authentication problems or different assumptions about the order of events. SIT is where those problems are meant to surface.


Where SIT sits:
  • •Unit and component testing check pieces in isolation
  • •Integration testing checks modules of one application working together
  • •System Integration Testing (SIT) checks whole systems and external services working together, end to end
  • •User Acceptance Testing (UAT) follows SIT: business users confirm the connected system does what they need


What SIT usually covers:
  • •Interfaces and APIs: request and response formats, error codes, retries and timeouts
  • •Data flow: that a record created in one system arrives complete and correct in the next
  • •Authentication between systems: tokens, certificates and service accounts
  • •Failure handling: what happens when a downstream system is slow, down or returns an error
  • •Batch and scheduled jobs: overnight syncs, exports and imports between systems


Common SIT mistakes:

The most frequent one is testing against mocks only. Mocks are useful early, but SIT needs the real (sandbox) versions of external systems, otherwise the integration problems it exists to find stay hidden until UAT or production. The second is unclear ownership: when an integration fails, both teams assume the other side is wrong, so every SIT defect should name the interface and the expected payload.


Best practices:
  • •Write SIT test cases per interface, with the exact request, the expected response and the expected data in the receiving system
  • •Run SIT in an environment that uses sandbox versions of the real external services
  • •Trace each integration test back to the requirement or interface specification it proves
  • •Re-run the SIT suite after any change to an interface, on either side

Examples

  • 1.An order placed in the web shop appears in the ERP within 5 minutes with the correct line items, tax and shipping address
  • 2.The payment provider sandbox returns a declined card, and the shop shows the right message and does not create an order
  • 3.A new employee created in the HR system is provisioned in the identity provider and can sign in to the internal tools the next morning
  • 4.When the CRM API times out, the integration retries three times, then queues the update and raises an alert

In BesTest

In BesTest you keep SIT test cases in their own folder (or pull them together with a Smart Collection rule), link each one to the requirement or interface it proves, and run them in a dedicated SIT test cycle. Failed steps create linked Jira work items, so integration defects keep their test context.

See System Integration Testing (SIT) in Action

Experience professional test management with BesTest. Free for up to 10 users.

Try BesTest Free