In software development, the goal is always to create a whole greater than the sum of its parts. System integration testing (SIT) is an often forgotten and underemphasized element of software testing that ensures those parts actually come together. Without that integration, there’s no sum and certainly no whole.
With the rise of the API economy and the popularization of microservices-based architectures, this challenge has only gotten more complex. Applications are increasingly amalgamations of many other software components, and the best ones are often the best because of how well they integrate all the moving pieces involved.
The proliferation of software components means a development and testing team’s ability to integrate those components effectively is essential to fully realizing all the development work that’s already been done. Without SIT testing, your application risks running fast enough to potentially break a record but tripping before the finish line.
What is system integration testing (SIT)?
System integration testing, or SIT, is a step in the development life cycle and software testing process that checks whether all the tested modules that make up an application actually work together as a whole once they’re combined.
With modern applications of even moderate size, separate teams are typically focused on separate modules and components. Even if each component is already tested and integrated with its adjacent ones, SIT is still necessary because emergent issues can crop up as components intersect and communicate. It’s for this reason, among others, that regression testing is often a key part of SIT.
The purpose of SIT
The primary purpose of SIT is to ensure the system as a whole — not just as disparate components — works as intended. SIT typically happens after general integration testing, which we’ll get into in the next section, but it’s most beneficial when performed often. SIT typically includes testing interfaces, data flow, and the functionality of relevant business processes.
Consider a fairly simple ecommerce application as an example. An ecommerce application has many components, including one for user authentication, one for the shopping cart feature, one for payment processes, and more.
As these features are developed or improved, developers will do continuous unit testing to ensure their code changes work and, later on, integration testing to ensure each new component connects well to the next.
After that, the testing team takes on SIT to check the resulting whole. In this example, testers might try to log in, add a product to the shopping cart, and process a payment method to test how all these components flow together.
SIT vs. integration, system, and UAT tests
The test pyramid highlights three core testing types: Unit tests, integration, tests, and end-to-end tests. As we’ve covered before, there’s a lot of disagreement about what should be included and whether these are really the best terms.
Another aspect of this confusion comes about when you consider testing types like SIT, which often sit in awkward parts of the pyramid in between and amongst other test types. These types are especially likely to get confused with others because the lines between different types of testing are often genuinely blurry.
The first and most understandable confusion is the distinction between SIT and integration tests. SIT, obviously, contains the same term (system integration tests vs. integration tests), but many teams also consider SIT to be a form of integration testing. In the typical testing process leading from unit testing to integration testing, SIT — whether a particular team gives it a separate term or not — is often the last form of integration testing before moving on to end-to-end tests.
The second confusion is the distinction between SIT and system tests. Again, SIT contains the word “system,” but the distinction is larger in this case. System tests, which some teams might call by a different name, include functional and nonfunctional tests that cover the entire application. In contrast, SIT focuses more specifically on functional tests that cover system integration. In SIT, for example, you wouldn’t test the user experience or present the current version to users for feedback.
Along the same line is the third confusion, user acceptance testing (UAT). SIT and UAT actually sit pretty far apart. SIT is entirely functional testing performed by developers and testers, and UAT is nonfunctional testing aided by users.
SIT approaches from manual to automation
Teams can approach SIT in a variety of ways, most of which are determined based on how they want to approach integration testing as a whole. Depending on the team and tooling, the below methods can involve a mix of automated and manual testing.
Bottom-up, top-down, and big-bang
In our guide to integration testing, we covered the bottom-up approach, top-down approach, and big-bang approach. The first two approaches test from the highest to lowest component (and vice versa), and the last tests all components at once as a single unit.
For teams that consider SIT to be another step in the integration testing process primarily, these approaches will largely be inherited from whatever approach they take for integration testing.
Strict testing plan with acceptance criteria
Some development and testing teams consider SIT a step that warrants approaches outside of what they might already be doing for integration testing. In these cases, these teams typically write out a well-defined testing plan and a list of acceptance criteria.
The testing plan typically tasks testers with, among other things:
- Identifying the components to be integrated
- Defining the interfaces between components
- Identifying stakeholders
- Determining test cases to be written and run
- Writing a schedule for the tests
After writing and following a test plan, testers then run the results by pre-determined acceptance criteria, which can include, among other things:
- Functionality of the interfaces between components
- Behavior of the overall system
- Validation of functional requirements
- Compliance with regulatory and industry standards
Acceptance criteria determine which requirements a project has to meet before teams can consider it complete.
Context-specific flexibility
Splitting the difference between these two approaches is a series of flexible approaches teams can adapt to their circumstances. The granularity of the SIT changes depending on the systems targeted for testing.
In a fine-grained approach, SIT will target down to the component level and verify system functionality from the lowest level up. In a moderate-grained approach, SIT will target the interface and test how all the components interact and communicate. In a coarse-grained approach, SIT will target the entire system or just an important portion.
The advantage of this approach is that you can change coarseness depending on the criticality of the systems being tested. For example, testers might perform fine-grained testing on mission-critical components and use coarser testing for less important components.
Advantages of SIT
The primary advantage of SIT is one that nearly all testing methods share: It’s easier and cheaper to catch a flaw in your application early rather than fixing it after it’s in production.
SIT fits this purpose well because users don’t encounter your application as a series of well-tested components; they encounter it as a whole. If, in the ecommerce example from earlier, a user can log in and process payments but can’t add products to their cart, the experience is essentially broken for them even if each component technically works in isolation.
The earlier and more often testers run SIT tests, the more powerful the advantages of SIT will be. As new components are built and integrated, testers can, for example, identify and rectify compatibility issues and data discrepancies as soon as they show up. Issues like these tend to get more difficult to solve as they fester while other components are built and added.
SIT only gets more important if there are legacy systems to integrate. With SIT, testers can quickly verify whether new components work with older ones and learn as soon as possible whether old components might need an upgrade or migration.
Additionally, if the business frequently makes code changes, SIT can be an important stopgap to ensure new changes don’t break the current system. These stopgaps also maximize flexibility for making repairs and pausing changes. If you add a bunch of changes and then test, you won’t be sure what’s breaking. If you have an SIT process ready, however, you can have a better idea of which change is causing which issue.
Don’t skip SIT tests
SIT tests are an important part of the testing process — even if your team calls them by a different name or considers them just part of integration testing.
As we’ve covered before, the proliferation of terms, metaphors, and models can often lead to more confusion than anything. It’s often useful to zoom out and see the purposes of these different approaches and steps, but it’s almost always worth it to return to what Oleksii Holub, a dev tooling consultant, calls “reality-driven testing.”
Learn from the many different approaches and best practices out there, but always return to the reality of your application and its particular needs. Depending on your specific needs, you might find SIT is just another step among many or a process that pays dividends the more you break it out and invest in it.
%3A%20A%20guide%20for%20developers%20and%20testers){kind=link}