SOA - Testers' Nightmare?

For IT staff, SOA is no longer just a technology, it represents a kind of new and more macro methodology to design and implement IT system. Then as for the implementing process of the whole IT system, if each step is implemented by considering in accordance with the angle of SOA, this will become the priority and difficulty of SOA project implementing process.

The development of interface exploitation leads to the development of SOA, interface canonical standardization is a prominent one of SOA advantages. From EAI to ESB of SOA, from different interfaces to standard Web Service, we can see the evolution of interface development and its standardization process.

As SOA is under this new structure and design method, interface contract becomes a mean to restrict service providers and service consumers. As for developing staff, the contract will be converted to WSDL or IDL, or this kind of files. With such a definition file, the developers from service providers and service consumers can develop collaterally. With this kind of new developing mode, a lot of services can be reused effectively, the efficiency and services of development can be extended effectively; in this mode, we can assign some tasks to other companies and partners. Speaking from this way, SOA also facilitates the software outsourcing and offshore development.
However, there is an old saying in China --- “Benefit will bring disadvantage.” the testers will have new challenges under this development mode.

Firstly, to assign the services to different development providers through the interface contract, how to make sure the interface quality and the SLA satisfaction degree for the inside of development providers.

Secondly, during a service assembling phase (a typical example is that the development of BPM flow has such kind of phase), how to effectively make sure the smoothly process of testing.

The first phase is the functional test of service developing phrase.

Those who have the experience of developing EAI system and interface system all know that interface test is a fussy and inefficient process. It is a big improvement for SOA to standardize the interface, but it also doesn’t solve the fundamental problem of interface test. For developers and managers, before the integration testing, it is painful to make sure each service functional test, it need a lot of work. But for the design and implementation based on SOA, this will avoid the bigger and more destructive risk during assembling phrase.

We know that interface contact always is word or excel document in real projects. It doesn’t describe the details of many technical implementations; the more ideal circumstance is to have the interface definition file --- WSDL, which is more accurate and refined. On the basis of having WSDL files, we can make some service simulator or the client simulator to simulate the transfer and implementation of services, but how to effectively cover all of the business logic needs the testers and business requirement staff to work scientifically and precisely.

There is a golden rule of interface development, don’t leave the problem to the integration testing. The earlier the problem found, the better.

System Integration Test
The second phrase: service system integration test or assembling test phrase.

According to the methodology description of SOA implementing process by IBM, there is a stage called Assemble. This stage describes particularly about Service Testing. But in my opinion, these problems describing the response are for the real business environment, the understanding of SLA is the keystone of the test during this stage.

This stage will also be involved in every synergetic test of each vendor, because for the integration test of developing service crossing many companies, how to coordinate these different organizations, or to use what kind of tools and means to provide the efficiency of integrated test hasn’t been mentioned in the related SOA documents and standards of each vendor and large integrated company right now. Therefore, for the testers, the details are hard to work, under the circumstance of lacking overall methodology guidance, how can the testers avoid entering a black hole of SOA testing?