How to Go about SOA Testing

Anadi Misra

SOA solutions and blueprints require quite a few critical decisions during design and implementation. The same applies to testing these solutions, as it is not just functionality and performance one has to take care of. Testing SOA solutions also requires testing interfaces and services that might be bringing together diverse systems or platforms and, of course, their performance and related aspects. And as it happens with any new technology, there is not much of maturity in this process and only a few choices of products or suites are available that help in SOA testing. In this article, we look into some of the vital points of SOA testing and also evaluate the Parasoft SOA Suite for the same.

What to test for
As SOA systems are a sea of services, ie, a complex integration of either Web services, mid-tier services or even legacy systems again exposed as services, the testing process requires looking beyond the conventional code and GUI aspects. We are not saying that you need not touch the conventional aspects, but the nature of SOA solutions is such that these tests do not remain the only important thing to take care of. The presence of services is not the only factor complicating SOA testing. Process flows in a SOA solution might involve multiple and diverse systems integrated to provide a flow that can utilize these diverse systems. In other words, the services implemented might be executed in a way that they interact in a particular order or path with various systems. In process terms, you have to test a complete integration framework keeping in mind business processes that run covering your existing intact systems from one end to the other. Also, the performance, vulnerability and functional tests should also be performed.

So even if you realize that it's more about testing the integration framework, what exactly to test in that? Well, here the interfaces are such that they create links between applications or systems, not within them. This brings out another critical aspect of testing. Most of the businesses have applications or systems that are catering to particular business units. Thus, your tests should start with unit testing the individual modules, then test the interfaces for the integration they provide and then the processes on the whole. Testing the processes and services is required as the test run will invariably include bits from diverse systems integrated by them and give you a first hand look into how correct the overall processes are.

The challenges
Now that we know what is to be tested, let us look into how to go about it and what challenges project managers face while doing SOA testing. As we mentioned earlier one should start with testing individual modules for their outputs. Project managers advocate two ways to testing SOA-one is testing smaller parts of the integrated system, or in other words, a part of the entire process flow and then testing the entire process and the second is end-to-end testing.

We feel testing integration in parts is certainly a better way as jumping to a complete end-to-end testing can open up a Pandora's box. It gets tough to analyze the flaws in integration if revealed by the end-to-end test as you have a huge set of things going wrong, or it might be a particular module or a particular transaction by the service or connectivity between either the services or the service and the underlying legacy system. So it is better to zero down on most of the issues we just stated early in the development cycle rather then getting lost into a sea of wrong things.

We know that any testing cycle has the element of repeatability. And here's where the horror story starts as the number of process flows and execution steps' combinations can be killing. Thus, when you get down to regression testing, keep in mind that firstly it is not a building from blocks kind of solution being tested but an assembly of systems or applications. Secondly, it is better to go for a regression library that can be executed after any changes are made. This is always the better way to go because it is more manageable.

The biggest problem you need to tackle in testing such solutions is the availability of the 'underlying' systems or application or even components. For instance, your integration might be bringing together, say, an internal application, one from a specific vendor or even data being received from data sources. All of their availability becomes highly important while going for integration testing in parts and end-to-end testing as well. A good way to tackle this is to simulate the existing applications or systems to avoid delays. So regardless of the scale or size of the project and the processes being created, it is always important that your SOA testing also follows the SOA philosophy, keeps in mind the diverse layer of systems and the processes that run integrating them. And, of course, you have to test for the processes running on top of these rather than checking the underlying system for output.

Source: PCQuest