A simple approach to system integration testing

Most applications today are service-oriented or n-tier, using a Web server, application server and one or more databases. Both architectures can become quite complex, comprising multiple components, servers and physical locations. Can changes in one tier or component cause problems in the others? The answer is a resounding maybe.

First, one should test the individual components of business logic, user interface, services and data access layers. This testing isn't really about evaluating the dependencies among systems, but nevertheless is vitally important. For example, if a change to component A makes component B stop working, maybe component A is broken. But before getting into the complications in their interactions, make sure A and B are both functioning as expected. 

Passing data from one system to the other may be the weak link in the chain.

Enterprise architectures often have complex interactions, which means that passing data from one layer to the other may be the weak link in the chain. How does one test these interactions?  In most cases, this is done either through SOAP testing or API testing. Assuming that the services have been fully tested, you'll need to ensure that a similar quality exists at the interfaces. Companies and other services utilizing your components have to have a high level of confidence that the quality and performance of those components meet their standards.

Additionally, you have to test not only your software, but also the SOAP or API interfaces.  There are specialized tools for this kind of testing, including SmartBear's Ready! API and Parasoft's SOAPTest. Although you may not need these specialized tools, making sure that the interfaces are sufficiently robust and high performing so as to add immediate value to any solution you propose.

Finally, if you are using a legacy component architecture such as Common Object Request Broker Architecture (CORBA), convince your organization to get out of it as soon as you can and use either traditional Web services or APIs. CORBA was both highly complex and difficult to test, and so most software teams have since moved on to more modern architectures.