What is System Integration Testing?
System Integration Testing (SIT) is the overall testing of the whole system which is composed of many sub-systems. The main objective of SIT is to ensure that all software module dependencies are functioning properly and the data integrity is preserved between distinct modules of the whole system.
SUT (System Under Test) can be comprised of hardware, database, software, a combination of hardware and software or a system that requires human interaction (HITL – Human in the Loop Testing).
From the context of software engineering and software testing, SIT can be considered as a testing process which checks the software system’s co-occurrence with others.
SIT has a prerequisite in which multiple underlying integrated systems have already underwent and passed system testing. SIT then tests the required interactions between these systems as a whole. The deliverables of SIT are passed to the UAT (User acceptance testing).
What You Will Learn:
- Need of System Integration Test
- The Granularity of SIT
- How to Perform System Integration Testing?
- System Testing Vs System Integration Testing
- System Integration Testing Vs User Acceptance Testing
- SIT Example
- SIT Techniques
- Recommended Reading
Need of System Integration Test
The main function of SIT is to do test dependencies between different system components and hence, regression testing is an important part of SIT.
For collaborative projects, SIT is a part of STLC (Software Testing lifecycle). Generally, a pre-SIT round is conducted by the software provider before the customer runs their own SIT test cases.
In most of the organizations working in IT projects following Agile sprint model, a round of SIT is conducted by the QA team before every release. The defects found in the SIT are sent back to the development team and they work on the fixes.
The MVP (Minimum Viable Product) release from the sprint goes only when it gets passed through SIT.
SIT is required to expose the faults that occur when interaction happens between the integrated sub-systems.
There are several components used in the system and they cannot be unit tested individually. Even if the unit is individually tested, then also there is a possibility that it can fail when combined in the system as there are many issues that arise when subsystems interact with each other.
Thus, SIT is very much required to expose and fix the failures before deploying the system at the user’s end. SIT detects the defects at an early stage and thus saves the time and cost of fixing it later. It also helps you to get earlier feedback on the acceptability of the module.
The Granularity of SIT
SIT can be conducted at three different levels of granularity:
(i) Intra-System Testing: This is a low level of integration testing that aims at fusing the modules together to build a unified system.
(ii) Inter-System Testing: This is high-level testing that needs interfacing independently tested systems.
(iii) Pairwise Testing: Here, only two inter-connected subsystems in the whole system are tested at a time. This aims at ensuring that the two sub-systems can function well when combined together presuming that the other sub-systems are already working fine.
How to Perform System Integration Testing?
The simplest way to perform SIT is through Data-driven method. It requires minimum usage of software testing tools.
First, data exchange (data import and data export) happens between the system components and then the behavior of each data field within the individual layer is examined.
Once the software is integrated, there are three main states of data flow as mentioned below:
#1) Data state within the Integration Layer
The integration layer acts as an interface between the data import and export. Performing SIT at this layer requires some basic knowledge on certain technology like schema (XSD), XML, WSDL, DTD, and EDI.
The performance of data exchange can be examined at this layer through the below steps:
- Validate the data properties within this layer against BRD/ FRD/ TRD (Business requirement document/ Functional requirement Document/ Technical requirement document).
- Cross check the web service request using XSD and WSDL.
- Run some unit tests and validate the data mappings and requests.
- Review the middleware logs.
#2) Data state within the Database layer
Performing SIT at this layer requires a basic knowledge of SQL and stored procedures.
The performance of data exchange at this layer can be examined through the below steps:
- Check if all the data from the integration layer has reached successfully at the database layer and has been committed.
- Validate the table and column properties against BRD/ FRD/ TRD.
- Validate the constraints and data validation rules applied in the database as per business specifications.
- Check stored procedures for any processing data.
- Review server logs.
#3) Data state within the Application layer
SIT can be performed at this layer through the below steps:
- Check if all the required fields are visible in the UI.
- Execute some positive and negative test cases and validate the data properties.
Note: There can be a lot of combinations corresponding to data import and data export. You will need to execute SIT for the best combinations considering the time available to you.
System Testing Vs System Integration Testing
Differences between System Testing and SIT:
|SIT (System Integration Testing)||System Testing|
|SIT is mainly done to check how individual modules interact with each other when integrated into a system as a whole.||System testing is mainly done to check if the whole system is working as expected with reference to the specified requirements.|
|It is conducted after unit testing and will be done each time when a new module is added to the system.||It is conducted at the final level i.e. after the completion of integration testing and just before delivering the system for UAT.|
|It is a low-level testing.||It is a high-level testing.|
|SIT test cases focus on the interface between the system components.||Test cases, in this case, focus on simulating the real-life scenarios.|
System Integration Testing Vs User Acceptance Testing
Here is the difference between SIT and UAT:
|SIT (System Integration Testing)||UAT (User Acceptance Testing)|
|This testing is from the perspective of interfacing between modules.||This testing is from the perspective of user requirements.|
|SIT is done by developers and testers.||UAT is done by customers and end users.|
|Done after unit testing and before system testing.||This is the last level of testing and is done after system testing.|
|Generally, the issues found in SIT would be related to data flow, control flow, etc.||The issues found in UAT would generally be like the features that are not working as per the user requirements.|
The image below on the levels of testing would make the flow from Unit testing to UAT clear to you:
Let us assume that a company is using software to store the client details.
This software is having two screens in the UI – Screen 1 & Screen 2, and it has a database. The details entered in Screen 1 and Screen 2 are entered in the database. As of now, the company is satisfied with this software.
However, a few years later the company finds that the software is not meeting the requirements and there is a need for enhancement. Hence, they developed a Screen 3 and a database. Now, this system having Screen 3 and a database is integrated with the older/existing software.
Now, the testing done on the whole system after the integration is called System Integration test. Here, the co-existence of a new system with an existing one is tested to ensure that the whole integrated system works fine.
Mainly, there are 4 approaches for doing SIT:
- Top-Down Approach
- Bottom-up Approach
- Sandwich Approach
- Big Bang Approach
The top-down approach and bottom-up approach is a kind of incremental approaches. Let us begin the discussion with Top-down approach first.
#1) Top-Down Approach:
Under this, the testing starts with just the topmost module of an application i.e. the UI which we call as a test driver.
The functionality of the underlying modules is simulated with stubs. The top module is integrated with the lower level module stub one by one and later the functionality is tested.
Once each test is completed, the stub is replaced by the real module. The modules can be integrated either in a breadth-first manner or depth-first manner. The test continues until the whole application is built.
The advantage of this approach is that there is no need for drivers and the test cases can be specified in terms of the functionality of the system.
The main challenge in this type of approach is the dependency on the availability of lower level module functionality. There can be a delay in tests until the real modules are replaced with stubs. Writing stubs is also difficult.
#2) Bottom-up Approach:
It eliminates the limitations of the top-down approach.
In this method, first, the lowest level modules are assembled to form clusters. These clusters serve as a sub-function of the application. Then a driver is created to manage the test case input and output. After this, the cluster is tested.
Once the cluster is tested, the driver is removed, and the cluster is combined with the next upper level. This process goes on until the whole application structure is achieved.
There is no need for stubs in this approach. It becomes simplified as the processing moves upward and the need of drivers get reduced. This approach is advisable for doing SIT for object-oriented systems, real-time systems, and systems with strict performance needs.
However, the limitation of this approach is the most important subsystem i.e. UI is tested at the last.
#3) Sandwich Approach:
Here, the top down and bottom up approaches discussed above are combined together.
The system is perceived as having three layers – the middle layer which is the target layer, a layer above the target and a layer below the target. Testing is done in both the directions and congregates at the target layer which is in the middle and this is illustrated in the below image.
Sandwich Testing Strategy
An advantage of this approach is that the top layer and the bottom layer of the system can be tested in parallel. However, the limitation of this approach is that it does not exhaustively test the individual sub-systems before integration.
To eliminate this limitation, we have modified sandwich testing in which the integration of the top, middle and bottom layers are tested in parallel using stubs and drivers.
#4) Big Bang Approach:
In this approach, integration is done once all the modules of the application are completely ready. Testing is done after the integration of all the modules to check if the integrated system is working or not.
It is challenging to find the root cause of the issue in this approach as everything is integrated at once as opposed to incremental testing. This approach is generally adopted when only one round of SIT is required.
In this article, we learned what is System Integration Testing (SIT) and why is it important to perform it.
We understood about the core concepts, techniques, approaches and the methods involved in performing SIT. We also walked through how SIT is different from UAT and system testing.
Hope you enjoyed this excellent article!!