System integration testing
In the context of software systems and software engineering, system integration testing (SIT) is a testing process that exercises a software system's coexistence with others. With multiple integrated systems, assuming that each have already passed system testing,[1] SIT proceeds to test their required interactions. Following this, the deliverables are passed on to acceptance testing.
Contents
Introduction
SIT is part of the software testing life cycle for collaborative projects. Usually, a round of SIT precedes the user acceptance test (UAT) round. Software providers usually run a pre-SIT round of tests before consumers run their SIT test cases.
For example, if an integrator (company) is providing an enhancement to a customer's existing solution, then they integrate the new application layer and the new database layer with the customer's existing application and database layers. After the integration is complete, users use both the new part (extended part) and old part (pre-existing part) of the integrated application to update data. A process should exist to exchange data imports and exports between the two data layers. This data exchange process should keep both systems up-to-date. The purpose of system integration testing is to ensure all parts of these systems successfully co-exist and exchange data where necessary.
There may be more parties in the integration, for example the primary customer (consumer) can have their own customers; there may be also multiple providers.
Data driven method
Lua error in package.lua at line 80: module 'strict' not found. A simple method of SIT which can be performed with minimum usage of software testing tools. Data imports and exports are exchanged before the behavior of each data field within each individual layer is investigated. After the software collaboration, there are three main states of data flow.
Data state within the integration layer
Integration layer can be a middleware or web service(s) which acts as a medium for data imports and data exports. Data imports and exports performance can be checked with the following steps.
1. Cross checking of the data properties within the Integration layer with technical/business specification documents.
- For web service involvement with the integration layer, WSDL and XSD can be used against web service request for the cross check.
- Middleware involvement with the integration layer allows for data mappings against middleware logs for the cross check.
2. Execute some unit tests. Cross check the data mappings (data positions, declarations) and requests (character length, data types) with technical specifications.
3. Investigate the server logs/middleware logs for troubleshooting.
(Reading knowledge of WSDL, XSD, DTD, XML, and EDI might be required for this)
Data state within the database layer
1. First check whether all the data have committed to the database layer from the integration layer.
2. Then check the data properties with the table and column properties with relevant to technical/business specification documents.
3. Check the data validations/constrains with business specification documents.
4. If there are any processing data within the database layer then check Stored Procedures with relevant specifications.
5. Investigate the server logs for troubleshooting.
(Knowledge in SQL and reading knowledge in [stored procedures] might be required for this)
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. Mark all the fields from business requirement documents which should be visible in the UI.
2. Create a data map from database fields to application fields and check whether necessary fields are visible in UI.
3. Check data properties by some positive and negative test cases.
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.
References
<templatestyles src="Reflist/styles.css" />
Cite error: Invalid <references> tag; parameter "group" is allowed only.
<references />, or <references group="..." />
