Other meanings of System integration
Software Testing
System integration testing (SIT) is a level of software testing that verifies that multiple subsystems or components work together as a whole, after individual unit testing but before system testing. It focuses on the interfaces between modules, data flow, and the interaction of integrated components, often using both top-down and bottom-up strategies. SIT is distinct from system testing, which validates the complete system against requirements, and from user acceptance testing, which checks business readiness. The goal is to expose defects in the interaction of integrated units, such as incorrect data passing, interface mismatches, or timing issues, before the system is delivered.
System integration testing aims to uncover defects that arise when individually tested components are combined, such as mismatched data formats, incorrect API calls, or race conditions. It operates at the level of the integrated system, using both stubs and drivers to simulate missing components, and it is typically performed by a dedicated test team rather than developers. Unlike unit testing, which checks isolated functions, SIT validates the interactions across module boundaries, often using real hardware or simulated environments. The scope includes both functional and non-functional aspects, such as performance under load and security of inter-module communication.1
Common strategies include big bang, top-down, bottom-up, and sandwich (hybrid) integration. In big bang, all modules are combined at once, which is simple but makes defect isolation difficult. Top-down integration starts with the top-level modules and uses stubs for lower-level ones, allowing early validation of control flow but requiring stub development. Bottom-up integration begins with low-level modules and uses drivers, facilitating early testing of core functionality but delaying top-level interface checks. Sandwich integration combines both, testing the system in layers, which balances early feedback and defect isolation. Each strategy has trade-offs in terms of test scheduling, stub/driver effort, and fault localization.
SIT is often confused with system testing, but it specifically targets interface defects, not requirement compliance. A lesser-known variant is continuous integration testing, where SIT is automated and run on every code commit, a practice popularized by agile methodologies. Another niche is integration testing of hardware-software systems, such as in automotive or aerospace, where timing and signal integrity are critical. Historically, the term 'integration testing' was used in the 1970s by pioneers like Glenford Myers, who emphasized the importance of interface testing in his classic book 'The Art of Software Testing'. Also, SIT often involves test data management across heterogeneous databases, which is a common source of subtle failures.
Key challenges include managing dependencies between modules, coordinating test environments, and handling third-party services. Best practices include defining clear interface contracts, using version control for test artifacts, and automating regression tests. A common pitfall is neglecting negative testing, such as passing invalid data across interfaces. Another is failing to test error handling and recovery paths, which often surface only in integration. Effective SIT requires a dedicated test environment that mirrors production, and it benefits from using service virtualization to simulate unavailable components. Finally, traceability matrices help ensure that all integration points are covered, reducing the risk of untested interactions.
This entry focuses on system integration testing as a distinct phase in the software testing lifecycle.
Help improve the encyclopedia. Reports go straight to the site manager.