Development and Maintenance of Homegrown Tools
Some IT teams may create their own tools, such as client emulators, in-house in order to facilitate functional testing. At the same time, a load generation tool may be purchased that requires proprietary scripts to be written. The creation and use of such homegrown tools and scripts not only adds overhead to the project, but such tools are also impossible to maintain as Web service complexity and industry standards evolve and mature.

Choose a single tool that can automatically generate a suite of test cases using WSDL and HTTP traffic. In addition, the ability to leverage tests from unit testing through load testing allows more test cases to be generated - ensuring greater coverage and quality of the service while minimizing business risks of production failure or production-level error.

Incomplete Testing
The scope of testing provided by in-house applications is generally limited and does not cover all of the aspects needed to verify a Web service. Aspects such as security, interoperability, functionality, reliability, and availability are not verified due to these limitations. As a result, businesses face an exponential increase in financial risk.

For example, rather than testing a Web service directly at the code level, organizations may utilize some GUI-based client to consume the Web service. However, dependence on GUI-based testing of a Web service is limited and restricted to only the types of messages that the GUI-based client is built to generate. With most Web ser-vices, it is impossible to anticipate exactly what types of requests clients will send. Real-world partners and consumers of a Web service are certain to send different types of requests, negative inputs, and bad data to the Web service that the GUI-based client has not even considered. In addition, maintaining and expanding a GUI-based testing application would result in numerous and unnecessary productivity losses in order to perform only limited, indirect testing of a Web service. In order to completely and thoroughly test a Web service, you must be able to emulate many of the types of clients that might access the server, and verify that the server will behave as expected in relation to any type of client request.

The best testing tools increase the scope of testing by providing the flexibility to manipulate messages in order to directly and thoroughly test the Web service. Tools should be able to perform code-based testing of the Web service and isolate and test the data at the API and message layer of the service. By testing the API and services layer, developers can verify whether the Web service can handle a wide range of request types and parameters. By checking for the conditions and inputs that are not expected, you enable more thorough tests for what cannot be foreseen. By performing such testing at the unit and application level, you can quickly and easily identify and correct any weaknesses before security breaches have the opportunity to occur.

Summary
As seen throughout this article, there are countless opportunities for things to go wrong during Web services development - a slight mistake in any component or interface will cause problems that ripple throughout the system. Developers must ensure that each part of the system is reliable, and that all of these parts interact flawlessly and securely.

As organizations rely more heavily on Web services to drive their business processes, it is critical for Web services developers to have a proven solution to test the complex layers of Web services and to create an efficient and bulletproof testing process without being riddled with the common problems discussed earlier. The Parasoft Web Services Solution not only provides clear and practical guidelines for testing, but also provides a cohesive team workflow that makes the most efficient use of project assets across the organization. To learn more about Parasoft Web Services Solutions, or any of Parasoft's Automated Error Prevention Solutions, please visit www.parasoft.com/SOAtest_WSJ.