System integration testing is process of verify the synchronization between two or more software systems and which can be completed after all the systems combined as one.
As an example if we are providing a solution for a client as extension/enhancement to their existing solution, then we should integrate our application and our DB with their existing application and existing DB.
After the integration process completed both software systems should be synchronized.
Which means if end users use our part of the integrated application (extended part) then our data layer might be updated than client’s, if end users use client’s part of the integrated application (existing part) then their data layer might be updated than ours. Then there should be a process to exchange data imports and exports between two sides. This data exchange process should keep both systems up-to-date.
This is a simple example which integration layer keeps synchronization between two parties. Usually there are clients and their customer parties (third party organizations) come in to action. So in real world applications we should keep synchronization between more than two parties.
But how we can make sure whether these systems are successfully integrated before our solution goes to live.
In general there are three main states which we can verify the data synchronization.
(Most of these tests are data driven)
Data state within the integration layer.
Integration layer can be a middleware or web service(s) which is act as a media for data imports and exports.
Perform some data imports and exports and check following steps.
1. 1. Cross check the data properties within the Integration layer with technical/business specification documents.
- If web service involved with the integration layer then we can use WSDL and XSD against our web service request for the cross check.
- If middleware involved with the integration layer then we can use data mappings against middleware logs for the cross check.
Some of the data properties
- - Type of criteria (Mandatory/Optional).
- - Data type.
- - Character length.
2. 2. Execute some unit tests.
Cross check the data mappings (data positions, declarations, requests) with technical specifications.
(Reading knowledge of WSDL, XSD, DTD, XML, and EDI might be required for this)
3. 3. Investigate the server logs/middleware logs for troubleshooting.
Data state within the database layer
1. 1. First check whether all the data have committed to the database layer from the integration layer.
2. 2. Then check the data properties with the table and column properties with relevant to technical/business specification documents.
3. 3. Check the data validations/constrains with business specification documents.
4. 4. If there are any processing data within the database layer then check DB procedures with relevant specifications.
(Knowledge in SQL and reading knowledge in DB procedures might be required for this)
5. 5. Investigate the server logs for troubleshooting.
Data state within the Application layer
There is not that much to do with the application layer when we perform a system integration testing.
1. 1. Mark all the fields from business requirement documents which should be visible in the UI.
2. 2. Create a data map from database fields to application fields and check whether necessary fields are visible in UI.
3.
3. 3.Check data properties by some positive and negative test cases.
If we can successfully perform these steps then we can verify the system integration has completed successfully.
There are many combinations of data imports and export which we can perform by considering the time period for system integration testing (We have to select best combinations to perform with the limited time). And also we have to repeat some of the above steps in order to test those combinations.
This is a simple IDEA about System Integration Testing.
Have Fun!
