Challenges in SOA test
Special considerations for the testing of SOA are:
The system will be called by many different systems.
* This means that good performance is very important. The SOA solution becomes central to many systems and poor performance and slow response times will be problematic for many other systems.
* The system that calls the SOA solution can be constructed in many different programming languages and be of many types: portals applications, BI systems, business systems. In order to easily be able to integrate with other system the SOA solution must have a standard interface.
* Since these systems all the time will depend on the SOA solution, it must have good reliability.
If any of the systems that call SOA solution has high demands on a specific area, for example that data is always completely accurate, so inherits the SOA solution that requirement. You can not just deal with requirements for SOA system itself, but the requirements for the calling system need to be considered.
The SOA system is itself dependent on other systems that hold the source data. The SOA system can for example retrieve data from an existing database, the economy system, the personnel system, etc. The problems these systems have will affect the operational safety of the SOA system. It is therefore important to have good error handling and alarm systems in SOA solutions to deal with different kinds of errors.
There is no GUI, all tests require that you have tools to work with. These tools require a good traingin of test personnel as well as a good tool strategy. One need from the beginning to think about how the tool can support you in the functional tests, how these scripts can be used in eg regression testing and performance testing.
The testing of webservices, it is often very many parameters that need to be verifed in the tests. Should a webservice return 30 parameters, it is a challenge to verify that all parameters are returned. In addition, you also need to ensure that the values are correct. And it can often be a combination of internal parameters to be used in the request, eg the logic of a Web interface, and the parameters to be displayed to the end user of the service via eg a web interface.
One dimension of looking at Web services is if they are combined or atomic. Web services can be atomic, that is, in itself account for the entire logic. An example would be an internal database that can be called via an internal Web service. The alternative is connected web services, for example using BPEL that connects multiple web services to create one service. Another dimension is the organizational - web services can be provided entirely in-house, that it is its own organization or project that has full control of the web service. It may also be external, or any other company providing the web service that your project uses to create an integrated service.