Timely delivery of a quality Web services solution requires functional testing at each layer, throughout the development process. New test automation solutions empower insurance domain experts to verify critical business processes at each phase and layer of delivery.

Web services promise insurance companies the ability to be rapidly responsive to both regulatory requirements and market opportunities by enabling changes to software systems without disrupting internal integration among applications or external integration with brokers, agents, and partners. Claims have long been filed electronically, but the standards that have emerged from HIPAA (Health Insurance Portability and Accountability Act) have further propelled the shift to electronic exchange of all transactions.

However because of the very power it unleashes - policies underwritten and issued, claims adjudicated and paid, all behind the scenes and screens - it is essential to assure the accuracy of the results, the privacy of the information, and the stability of the infrastructure. Incorrect responses can reduce revenue or increase losses, security breaches can compromise patient confidentiality, and failure can disrupt operations within and across enterprises.

Unfortunately, the layered architecture that powers Web services challenges traditional testing approaches, which have historically relied on subject matter experts interacting with end user applications. While these applications may invoke Web services under the covers, they provide indirect testing at best, and issues uncovered at the application level may have originated in one of the lower layers. Furthermore, interactions with external providers or consumers are even more difficult to test because they require predictable, repeatable transactions. As a result, most business process assurance verification has been left to the final phase of implementation when defects are the most costly to diagnose and correct.

The good news is that a new breed of test automation solutions is now emerging to specifically target application domain experts, and bring them into the early stages of the test process by providing a level of abstraction that masks the underlying technical complexities of a service-oriented architecture (SOA). These solutions can simulate or isolate each layer of the implementation, both internal and external, and enable functional testing to occur at each level and layer to assure that the final delivery is not only technically sound and delivered in a timely manner, but that it meets all business and regulatory requirements.

These challenges and solutions, described more fully below, are central to keeping pace in the new electronic insurance marketplace while minimizing business risk.

Web Services Implementation
The implementation of Web services though an SOA typically starts from the bottom up, first with the technical infrastructure, including the transport protocol and message encoding, followed by the integration of provider and consumer applications, both internal and external.

Systems architects or developers often have tools available to test these lower layers for technical compliance, but their deficiency of subject-matter expertise limits their ability to identify the more subtle business rule or logic errors that can potentially be more devastating than the more obvious errors. Additionally, these tools are designed to test the correctness of the data transport and format - in other words the technology infrastructure - but not the transaction content, namely the business application for the data.

Another drawback with infrastructure-specific tools is that they are rarely integrated with higher-level test management, reporting, and analysis capabilities. Like unit test tools for developers, these are typically point solutions that meet a highly specialized technical requirement but do not provide support for the higher-level information management of the testing process.

Because of their technical nature, these tools are not accessible to business experts, and until now, the only way to involve subject matter experts in early-stage testing was to develop even more software that provided primitive user-test interfaces and stubs. Users were often required to struggle through the editing of highly complex XML message structures to construct or verify the desired data values, and they could then use these testing interfaces and stubs to send or receive the messages from either dummy queues or from actual transports and the applications behind them.

All of this development effort ultimately diverted time and resources from the delivery of the end solution. Subject matter experts spent the majority of their time dealing with technology details rather than applying their knowledge to ensuring that the business problems at hand were being addressed properly. As a result, functional testing of Web services was typically left until the final stage of integration with the end user applications.

However, waiting until the final end-user layer is in place to test business functionality delays the time to market by postponing the discovery of issues and obscuring their source. Furthermore, performing an integrated end-to-end test requires predictable, repeatable transactions, yet all internal and external systems may not be available at the same time, or may not be easily simulated to test interactions throughout the supply chain.

Web Services Testing
Today, there is a new class of functional test solutions emerging to support end-to-end functional testing of SOA at each stage of the development process. These tools provide a universal GUI interface that is analyst-friendly, does not require any technical skills, and empowers subject matter experts to construct, send, receive, and verify messages using files, transports, or the actual applications. These same tools also support testing of the consumer and provider applications through their traditional user interfaces, thus enabling true end-to-end testing, as well as isolating a single layer or point of interface. (see Figure 1)

Briefly, these tools map the message formats into their data elements and present these to the user in a drop-down, point-and-click interface. Users simply select the type of message they wish to send or receive, then supply the data values for each element to be created or verified. Default values from template messages can be used as a starting point, and only values that are pertinent to the particular type of test need to be supplied.

Once the message contents are defined, users can select from another set of options as to the target or source, such as a file for a simulated interface, or an actual transport for live interaction. This option can be modified as needed, so that when a new layer or application comes online, the target or source can simply be changed without affecting the message.

For example, users can isolate the transport by constructing and sending, or receiving and verifying messages to and from files, instead of actual provider or consumer applications, thereby assuring that the message queues are functional, the encoding is correct, and the content integrity is maintained. They can also isolate a single application by sending or receiving messages from between the application and a file, instead of from the actual queue. By isolating each layer, issues can be quickly uncovered at their source and before they are proliferated to other layers.

As the architecture nears completion, users can selectively integrate each component into the whole, until they can finally test end-to-end from the provider application, through the transport, to the consumer application. At each stage, not only is the technical infrastructure being exercised but, more important, the actual message content and supported business process as well.

Since these advanced tools can be used throughout all layers of Web services, they can even simulate the correct behavior of faulty components so that the overall integration can continue while the malfunctioning component is fixed. This capability speeds time-to-market and bypasses delays that otherwise slow down test activities.