Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
What is System Integration Testing (SIT) with Example
What exactly is System Integration Testing (SIT)?
System Integration Testing is a sort of software testing that is performed in an integrated hardware and software environment to evaluate the overall system behavior. It is testing performed on a whole, integrated system to determine the system's compliance with the stated requirements.
System Integration Testing (SIT) is used to validate the interactions of a software system's parts. It is responsible for validating the high and lowlevel software requirements contained in the Software Requirements Specification/Data and the Software Design Document.
It also validates the cohabitation of a software system with others and checks the interaction between software application components.
Modules are separately evaluated before being integrated to form a system in this sort of testing.
For example, software and/or hardware components are gradually merged and tested until the complete system is integrated.nt.
The Need for a System Integration Test
Because the primary goal of SIT is to examine the relationships between different system components, regression testing is an important component of SIT.
SIT is a component of the STLC for collaborative projects (Software Testing lifecycle). In most situations, the software supplier does a preSIT round before the customer performs their own SIT test cases.
The QA team does a round of SIT before each release in most businesses that work on IT projects using the Agile sprint methodology. The problems discovered in the SIT are returned to the development team, who work on the remedies.
The sprint MVP (Minimum Viable Product) is released only when it has passed through SIT.
SIT is necessary to highlight the errors that arise when the integrated subsystems interact.
The system contains numerous components that cannot be unit tested independently. Even though the unit is independently tested, it is possible that it will fail when integrated into the system due to the numerous problems that occur when subsystems interact with one another.
As a result, SIT is essential for exposing and correcting errors before deploying the system to users. SIT discovers problems at an early stage, saving time and money on later repairs. It also allows you to obtain earlier input on the acceptance of your proposal.
SIT Granularity
SIT Granularity may be performed at three distinct granularity levels −
Intra-System Testing − This is a low-level integration test that wants to connect the modules to produce a unified system.
Inter-System Testing − This is a high-level test that requires the interfacing of independently tested systems.
Pairwise Testing − In this method, just two interconnected subsystems in the entire system are tested at the same time. This is done to ensure that the two sub-systems operate effectively when merged, assuming that the other sub-systems are already operating well.
How Do You Carry Out System Integration Testing?
The data-driven technique is the easiest way to execute SIT. It necessitates the use of only a few software testing tools.
First, data exchange (data import and export) occurs across system components, followed by an examination of the behavior of each data field inside the particular layer.
Following the integration of the program, there are three major states of data flow, as listed below −
#1) The status of data within the Integration Layer The integration layer serves as a bridge between data import and export. SIT at this layer needs some fundamental understanding of technology like schema (XSD), XML, WSDL, DTD, and EDI. The following procedures can be used to assess the performance of data exchange at this layer −
Check the data characteristics in this layer against the BRD/ FRD/ TRD (Business requirement document/ Functional requirement document/ Technical requirement document).
Using XSD and WSDL, double-check the web service request.
Validate the data mappings and requests by running some unit tests.
Examine the middleware logs.
#2) The status of data within the Database layer SIT at this layer needs a rudimentary understanding of SQL and stored procedures. The following procedures can be used to evaluate the performance of data exchange at this layer −
Check to see if all of the data from the integration layer has been successfully sent to the database layer and committed.
Validate the characteristics of the table and columns against the BRD/ FRD/ TRD.
Validate the constraints and data validation rules used in the database in accordance with the business standards.
Check for any processing data in stored routines.
Examine the server logs.
#3) The application layer's data state SIT may be done at this layer by following the procedures below −
Examine the UI to see if all of the needed fields are visible.
Validate the data characteristics by running various positive and negative test scenarios.
It should be noted that there are several possibilities for data import and data export. You will need to use SIT to find the optimal combinations given the time constraints.
Integration Testing Entry and Exit Criteria
Typically, the ETVX (Entry Criteria, Task, Validation, and Exit Criteria) method is utilized while doing Integration Testing.
Criteria for Entry
Completion of Unit Testing
Inputs
Software Requirements Data
Software Design Document
Software Verification Plan
Software Integration Documents
Activities
Create test cases and processes based on the high and low-level requirements.
Builds of low-level modules that implement a common feature should be combined.
Create a test harness.
Put the build to the test.
When the test passes, the build is merged with other builds and tested until the system is fully integrated.
Rerun all of the tests on the target processor-based platform and record the results
Exit Criteria
Completion of the Software module's integration on the target Hardware Correct software performance in accordance with the specifications
Outputs −
Reports on integration tests
[SVCP] Software Test Cases and Procedures
SIT Example
Assume a firm is utilizing software to keep customer information. This software contains two screens in the UI – Screen 1 and Screen 2 – and a database. The information entered on Screens 1 and 2 is saved in the database. For the time being, the firm is pleased with this program.
However, a few years later, the firm discovers that the software is not matching the criteria and that it has to be improved. As a result, they created Screen 3 and a database. This system, which includes Screen 3 and a database, is now connected with the older/existing software.
Example of System Integration Testing
The testing performed on the entire system following integration is now referred to as the System Integration test. The coexistence of a new system with an old one is evaluated here to guarantee that the entire integrated system functions properly.
Techniques for SIT
There are four main ways of performing SIT −
Top-Down Approach
Bottom-up Approach
Sandwich Approach
Big Bang Approach
Top-down and bottom-up methods are both gradual techniques. Let us start with a top-down approach to the debate.
Top-Down Approach In this approach, testing begins with only the topmost module of an application, i.e. the UI, which we refer to as a test driver. Stubs are used to imitate the functionality of the underlying modules. The top module is merged one by one with the lower level module stub, and the functionality is then tested. The stub is replaced with the genuine module once each test is done. The modules can be combined in either a breadth-first or a depth-first fashion. The test will continue until the entire application has been created. The advantage of this method is that no drivers are required, and the test cases may be defined in terms of the system's functionality. The primary difficulty with this method is the reliance on the availability of lower-level module capabilities. There may be a test delay while the genuine modules are replaced with stubs. It is also tough to write stubs
Bottom-up Approach It overcomes the drawbacks of the top-down approach. First, the lowest level modules are combined to create clusters in this technique. These clusters provide a specific role inside the program. The test case input and output are then managed by a driver. Following that, the cluster is tested. After testing, the driver is removed and the cluster is merged with the next higher level. This procedure is repeated until the entire application structure is completed. This method eliminates the requirement for stubs. It becomes simpler as the processing level rises and the requirement for drivers decreases. This method is recommended for doing SIT on object-oriented systems, realtime systems, and systems with stringent performance requirements. The disadvantage of this method is that the most essential component, namely the UI, is tested last.
Sandwich Approach In this approach, the top-down and bottom-up approaches mentioned before are merged. The system is considered to have three layers: the target layer in the center, a layer above the target, and a layer below the target. Testing is done in both directions and congregates at the target layer, which is in the center, as seen in the figure below. This method has the benefit of allowing the top and bottom layers of the system to be evaluated concurrently. The drawback of this technique is that it does not thoroughly test the various sub-systems before integration. To overcome this restriction, we redesigned sandwich testing such that the top, middle, and bottom layers are tested in parallel using stubs and drivers.
Big Bang Approach In this approach, integration is completed after all of the application's modules are complete. After all of the modules have been integrated, testing is performed to determine whether or not the integrated system is operational. Because everything is merged at once rather than incrementally, it is difficult to discover the core cause of the problem in this method. This method is often used when only one round of SIT is necessary.
4K+ Views
