Introduction
Many insurance companies rely on disparate technology solutions to quickly
bring products to market, process claims and service customers. But the homegrown and customized legacy systems on which many companies have built their businesses often are not flexible enough to quickly address market demands. By adopting service-oriented architecture.
Introduction
Many insurance companies rely on disparate technology solutions to quickly
bring products to market, process claims and service customers. But the homegrown and customized legacy systems on which many companies have built their businesses often are not flexible enough to quickly address market demands. By adopting service-oriented architecture, insurance companies are successfully distributing existing systems across the enterprise in a more cost-effective manner.
Since customized legacy solutions tend to be hard-coded and operate
independently among departments, they create silos of information. To make matters worse, a single insurance carrier has invested in multiple independent solutions to conduct billing, claims, even underwriting processes.
Thus, carriers are looking for solutions that will break down silos, reuse data and business logic, and deliver "one view of the customer". While costly, cumbersome point-to-point integrations were historically the only option, Web services are emerging as a favorable alternative.
Maturing Standards
While SOA is unofficially called the "next generation" of systems integration,
this concept would not be possible without the maturity of open standards. "The need to connect different sources of information located in various applications on various platforms throughout the organization is driving standards-based architecture". SOA exposes business applications as service components and allows different applications to link, interact and share data with each other using open industry standards. The flexibility
of using open standards and protocols also facilitates enterprise application integration, WhitePaper_Insurance_testing Page 3 2007
business-to-business integration and application-to-application communication across the Internet and corporate intranets. A recent XML standard for the insurance industry, ACORD XML consists of nearly 600 standard messaging formats in XML that execute transactions and exchange policy information across property/casualty, life and reinsurance.
How Web Services can be used in Claims Processing
In claims management, adjusters and examiners investigate claims, negotiate
settlements and authorize payments, while investigators deal with claims in which fraud or criminal activity is suspected. Insurance companies and independent adjusting firms employ adjusters, appraisers, examiners and investigators to handle claims, interpret and explain policy or regulations, and resolve billing disputes.
With a Web services-based claims system, claims adjustors can from a single screen access policy information and current claims data. Litigation managers can view current billing and case studies. Agents can make address changes without ever contacting a call center. Improvements from such a system include reduction in claims processing expenses, faster claims processing and better customer satisfaction. Claims submission and tracking allow agents to submit claims data directly into the claims process as follows:
-
Virtual claims centralization assigns tasks to claims agents most qualified to address a specific type of claim.
-
Document capture and processing spawn retrieval processes when required.
-
Claims rules assure greater consistency among claims resolutions.
-
Tracking capabilities allow enterprises to track individual claims status in real time.
Challenges for Testing
The SOA and integration testing world is a world of "behind the screens" testing where defects in the systems are some of the most elusive to find - and most expensive to correct. One defect can cause a domino effect of poor quality across business processes and supporting systems.
-
Defects in the SOA space are extremely difficult to diagnose because the data in messages is buried in transport protocols that are inaccessible to the typical tester and system administrator. As a result, these defects usually aren't seen until the full system can be tested at the very end of the project, after potential problems have multiplied throughout the system and are more costly to fix.
-
XML content and messages that are transmitted back and forth in an SOA environment often encapsulate the actual substance of the message, plus the function that it's supposed to perform. These messages are often written in SOAP (Simple Object Access Protocol), and may contain many customized formats and fields. An error can occur anywhere in the large number of fields, creating an enormous set of permutations and error points and making it extremely hard to have an effective testing solution around just the Web Services.
-
Web Services and SOA demand very explicit and predictable inputs and outputs. This largely hinges on the accuracy of the application programming. For example, in Microsoft Excel each cell must be formatted to accept the proper data. Cells for dollar figures must accept dollar signs; cells for decimals must accept decimal points, etc. Unless this is explicitly expressed at the API level, errors in message
communication can abound.
-
The SOA testing model isn't just about unit testing. When businesses build an SOA or integration initiative, they're pulling and modifying data from dozens of different systems. Many systems provide only a confirmation message that a process, such as an update, has occurred. There's no guarantee that the data that came from System x, that's now in System y, is accurate or has been put in the right place. Again this opens the door for error if the update is affecting multiple systems and isn't executing correctly.
-
Traditional testing is focused on the front-end. It involves checking aspects of the application that can be readily seen such as proper performance levels and the correct working order of all connections and interfaces. SOA and integration testing isn't focused on the GUI. It's focused behind the screen on the middle tier including application servers, enterprise services buses, legacy assets, and connection points between systems. SOA and integration testing is a headless,
almost stateless, environment with very low human visibility or interaction.
The Solution
The most effective way to validate SOA business processes is through a
continuous end-to-end testing process that inspects each layer of the SOA and integration infrastructure as it's developed, run, and maintained. Further, the ability to see deep inside the SOA and integration environments provides an ROI that's vital to a streamlined and cost-effective business.
SOA Test Approach
The approach for testing an SOA is that the test design should be top down, and test execution should be bottom up. Its important to engage SMEs throughout the development life cycle to ensure compliance not only with technical specifications but also with business requirements. SMEs should take part in defining the WSDL for each business process and also render help in testing the business process.
-
WSDL validation can be considered as the first step in testing Web Services
1. Validate with WSDL Schema
2. conformance check against WS-I's Basic Profile 1.1
3. Regression testing of WSDL
-
Next step is Unit Testing. By requiring the development of unit tests before or during, and not after, the development of the code, it can be ensured that the code provides the necessary functionality.
Functional Testing
From a testing standpoint, there are four main things to verify about SOAP client and server.
Client Testing
-
Whether the client can correctly initiate an interaction by sending a request
-
Whether the client behaves as expected when it receives a response.
Server Testing
-
Whether the server behaves as expected when it receives a valid request after sending a response
-
Whether the server generates an appropriate response for invalid requests
Functional Testing is accomplished by combining a series of operations into a
complicated scenario that emulates potential client behavior. Web Services client developers typically only have access to interfaces (WSDLs) and lack access to code.
Critical part is 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.
-
A Web Services tester can use details from WSDL such as the location of the Web Service, and the transport protocol, data types, etc., that provide significant leverage for authoring intelligent, efficient, and highly targeted test cases.
-
Test cases should be designed based on the WSDL by emulating all the data options available, including negative testing. Any off-the-shelf tools that can generate numerous XML requests based on the WSDL can be used.
-
Testing of the transport medium like HTTP, JMS SMTP etc should be taken care.
Automated Testing
-
A Test harness can be designed that can consume all the SOAP/XML requests and invoke the web services through supporting API (e.g. Apache AXIS).
-
The SOAP requests that are consumed by the test harness are stored in the form of request templates. These request templates need to be updated dynamically through some automation tool with the use of data driven testing.
-
The SOAP/XML responses that are returned should also be validated for conformance to the specification.
Security Testing
Web Services do not provide any standardized security services, although some aspects of security can be dealt with at transport protocol level. Flexibility is the enemy of Security. Web Services allows the use of existing technologies such as X.509 public-key certificates, XML-based tokens, Kerberos shared-secret tickets, and password digests.
Security testing should check for impersonation of the requester, impersonation of the service provider, unauthorized modification of data, disclosure of information, denial of service, and repudiation of action. The responses returned should be evaluated for anomalies, governance violations, proprietary data leakage, or any other criteria that represents a vulnerability risk. Also, the web services conformance to WS-Security specification should be verified.
Identity Management: With chained web services where a web service may call a number of downstream web services, identity must be carried as a part of the content within the SOAP/XML message as SAML assertions. Within such environments, each SAML assertions validity at every node has to be established. SOA testing such environments with Identity requirements across chained web services is complex and requires specialized SOA Testing products.
Interoperability Testing
The core technologies that comprise Web services (SOAP, WSDL, and XML)
are designed to ease interoperability and integration. However, the mere adoption of these technologies does not guarantee seamless interoperability. The main problem that developers face today is that they sometimes inadvertently introduce platform-specific features into the Web services that they develop. For example, a developer may expose only a Java solution without considering the effects on a .NET client.
Ideally, interoperability would be verified by checking that a service adheres to a comprehensive, universally implemented set of standards. With the announcement of Basic Profile 1.1 by the Web Services Interoperability (WS-I) organization, developers now have a set of standards to follow. Basic Profile 1.1 (BP 1.1) consists of implementation guidelines that define how core Web services specifications should be used together to develop interoperable Web services.
To test the services for interoperability, a test environment that can simulate various client environments like J2EE, .NET, AXIS, etc, should be built and tested against them.
Life Cycle Testing
If the Web Services are maintained in parallel and multiple versions, then the
test strategy should also involve testing each version of the service. If the versions are backward compatible, then the old client as well as the new client can access the services, but if there is a non backward compatible version, the old clients will fail to get the response from the server. Whenever changes are made to the services, unit and functional testing should be performed on the service. Test the new and old versions in parallel for the timeframe that has been allocated in the versioning plan of the web services.
Performance Testing
It assesses the throughput and response time characteristics of the back-end server through measurement diagnostics of tests and test sequences under concurrent client load. Traditional load/performance test tools can be used to test the performance.
Testing the Integrated Insurance Application
Once the application is ready to be tested, a build acceptance test is exercised
against this. This test typically verifies whether the build is testable. The build acceptance test is generally a short set of tests, which exercises the mainstream functionality of the application software. The next step is to conduct a smoke test on the application. It verifies the major functionality at a high level in order to determine if further testing is possible. The Smoke test scenarios should emphasize breadth more than depth. All components will be touched, and every major feature will be tested briefly. If test fails,
the build is returned to developers un-tested.
Functional Testing
Functional testing covers how well the system executes the functions it is
supposed to executeincluding user commands, data manipulation, searches and business processes, user screens, and integrations. Functional testing covers the obvious surface type of functions, as well as the back-end operations.
Individual components and processes can be tested early on, even before it's
possible to do functional testing on the entire system. For testing the functionality of an integrated insurance application, the first step is to identify the different subsystems like claims processing, policy administration, underwriting, rating system & billing systems.
After the subsystems are identified, positive and negative tests are exercised on these systems. The test cases have to be designed to test the functionality of each of these systems. Business analysts should involve in identifying the functional scenarios that can be used for generating test cases. Some sample tests that can be conducted on the Claims processing system can be Entering a claim, Classifying the claim (e.g.: property/Causality for general &
Death/Maturity for Life Insurance)
Validating the inspection report.
Determine whether the customers insurance policy covers the loss and how much of the loss should be paid to the claimant.
If, the claim validation is satisfactory, then claim is honored.
If, the claim validation is unsatisfactory, then claim is rejected.
If, the claim validation is under litigation, then claim is withheld for the courts
decision.
Similarly the underwriters system can be tested based on the pricing model
associated, like calculating the Gross Rate, Gross Premium, Net Rate, Net Adjustment, Total Deposit, etc,.
Integration Testing
Integration Testing is conducted in 2 phases. The point-to-point integration test phase focuses on testing the dependencies between the subsystems identified earlier. The end-to-end integration test phase focuses on testing the system as a whole by identifying end-to-end business scenarios.
Point-to-Point Integration Testing
The first step in the point-to-point integration testing phase is to identify the
dependencies that exist between the different sub systems like Claims Center, Policy administration system, rating and the like. Once the dependencies are captured, the direction of information flow between the systems should be identified. Now, each of these dependent systems is tested using identified test data. In the point-to-point integration approach, the output from each subsystem is carried as input to the identified dependent system.
A sample point-to-point integration test can include testing the Claims Center in integration with the Policy administration system. A test can be conducted on whether the policy associated with a beneficiary in the policy administration system reflects on the Claims system when the same beneficiary acts as a claimant when he claims for a loss that he has incurred. Also, for approving the claim, its necessary to check whether the
claimant has paid all the premiums that are due. So, in the above cases, the information from the policy administration system flows as an input to the Claims system.
The following steps are followed in this phase:
- Identify the dependencies between the sub systems
- Identify the scenarios for testing the information flow between these systems
- Identify the test data
- Perform functional testing which includes positive as well as negative testing.
End-to-End Integration Testing
The end-to-end integration testing phase involves identifying and testing the
end-to-end business scenarios. In this phase, the focus should be on testing the system as a whole. Business analysts should take part in identification of the end-to-end business scenarios. These scenarios should simulate the real time usage of the application. A sample end-to-end business scenario is something like add beneficiary information, issue quote/policy, reinsure policy, enter a claim, investigate on claim, calculate loss, settlement of claim amount, recover claim amount from reinsurer, notify on policy renewal.
The following steps are followed in this phase:
- Identify the end-to-end business scenarios
- Identify the test data
- Perform functional testing which includes positive as well as negative testing.
Exploratory Testing
While a team of testers is deployed to test the functionality based on scripted
requirements, exploratory testing should be performed by testers who are domain experts to improvise existing scripted tests and regression testing based on old bug reports.
Exploratory testing is simultaneous learning, test design, and test execution. When a tester has the skills to listen, read, think and report, rigorously and effectively, without the use of pre-scripted instructions, the exploratory approach to testing can be many times more productive (in terms of revealing vital information) than the scripted variety. And when properly supervised and chartered, can produce useful results that would not have been anticipated by a script. The social energy of people working together, hunting for bugs on the same software at the same time, often leads to more and better ideas than
would otherwise come out if the same people worked independently. A test coverage guide should be used to organize the test effort. This guide may take the form of a test coverage outline or matrix, a list of risks, or even an old fashioned To Do list.
Building the Regression Test Suite
Regression testing is required to ensure new builds do not regress or change
previous functionality. It is nothing but a selective retesting. Regression testing demands a strategy in which we limit the number of tests to establish an effective baseline measurement. Thus, the key to an effective regression testing strategy is to design a test suite that provides a high degree of confidence without retesting everything.
Deciding what tests to include in the regression test suite The most effective regression test suites include two categories of tests. The first category of tests includes high priority tests for commonly expected functionality
(e.g. the 20% of the product that 80% of the customers demand or rely on). The second category of tests includes any functional defects that are found and fixed. Found and fixed functional defects are included because fixed defects do occasionally regress, and if a business decision was made previously to fix a defect then we probably want it fixed before we release the product
Prioritized feature area/functionality buckets
The tests in the regression test suite should also be partitioned into functional
areas and each test in each functional partition or basket should also be prioritized based on risk assessment criteria. If the regression test suite is especially large or time is limited, and the regression suite is portioned into functional areas (and those areas are mapped to the project files or modules contain that specific functionality and any dependencies) the regression test pass can execute a limited subset of tests from the regression test suite that strategically target the modules that have changed (and tests for
dependent modules as well). Simple directory comparison tools (ex: Diff2Dirs), and tools to identify dependencies between modules (ex: Depends) are useful in identifying which modules change between builds and to map out dependencies between the modules in each build.
Automate
Since the regression test suite will ideally be run on each new build, this is one suite of tests that should be automated. Similar to the BVT/BAT test suite the purpose of WhitePaper_Insurance_testing Page 12 2007
the regression test suite is not necessarily to expose defects; a regression test suite provides baseline measurement of functionality. Therefore, since these are tests that will be ran several times during the software development lifecycle and are not necessarily designed to expose new defects the ROI for automation is very high.
Conclusion
The increasing trend of Mergers & Acquisitions in the Insurance Industry
has not only resulted in increased competition, but has brought the need to unify systems built on diverse platforms to the forefront. Insurers are expected to handle large volumes of business while providing quick and accurate services to customers across various business cycles such as Underwriting, Policy Distribution and Administration, Billing,
Claims Processing etc. This paper attempts to highlight some of the challenges and testing methodologies for testing SOA based, distributed Enterprise Insurance Applications.
