IT Operating Environments Best Practices - Systems Integration Testing (SIT) - validating external integrations and component interactions
IT Operating Environments Best Practices
Systems Integration Testing (SIT) - validating external integrations and component interactions
Overview
The Systems Integration Testing environment is where developers and engineers validate the behavior of their solution in the context of the external systems, applications, and components it will interact with in Production. DEV testing - unit testing and module testing - validates the internal correctness of the solution in isolation. SIT testing validates whether the solution interacts correctly with the external world: the APIs it calls, the databases it reads from and writes to, the message queues it publishes to and subscribes from, the authentication systems it integrates with, and the downstream systems that consume data it produces. Integration failures that are not caught in SIT consistently produce Production incidents that are more disruptive and more expensive to remediate than the integration testing that would have prevented them.
Best Practice
Govern the SIT environment as the first environment in the pipeline that tests the solution’s behavior in the context of the external systems it depends on and the external systems that depend on it. The SIT environment should be connected to representative stubs, mocks, or lower-environment instances of all external systems the solution integrates with, configured to behave consistently with Production integration behavior at the protocol and data format level while not exposing Production data or Production system state. Where external systems do not have lower-environment instances available, negotiate with their owners to establish SIT-accessible endpoints or representative stubs before SIT testing begins.
SIT environments are technical environments: their primary population is engineering teams. Business stakeholders are not involved in SIT validation. The gate artifact for promotion from SIT to UAT should include documented evidence of successful integration tests for all in-scope integration points, with explicit sign-off from the engineering team lead confirming that all integration test criteria have been satisfied.
Benefit(s)
A well-governed SIT environment catches the integration failures that unit and module testing in DEV cannot detect because those failures emerge only when the solution interacts with external systems under realistic integration conditions. Integration bugs caught in SIT are fixed in the development cycle, before the solution is presented to business users in UAT, avoiding the credibility and rework costs of presenting a solution with integration defects to the stakeholders whose approval is needed for Production promotion. The organization develops a delivery discipline in which integration quality is validated as a standard step before functional validation begins, rather than as an afterthought discovered when integration failures produce user-visible defects in UAT or Production.
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers