Testing insurance software can be divided into front, middle and back office. When we examine the front office, we pay attention to the UI part. The front office is used by insurance agents and insurance company employees. For insurance agents, they use the software to create or help a customer create a file and apply one or more types of insurance. Insurance company employees then communicate with the agents by accepting or rejecting the application.

However, the front office is just a small part of the whole system. There are other components that need to communicate with the front office. XML is one of the predominant data formats used for this communication. Actually, the front office is just a UI part for the end user, after the user clicks ‘apply’, all the information will be integrated into a XML file and sent to the middle and back office. The middle and back office will use the information in the XML message and execute a task, such as the calculation of the final payment, and then send another XML file back to the front office. Finally the message is shown in the front office software to the end user.

Data Verification Testing – XML

To test insurance software, we need to have detailed knowledge of the insurance processing flow, how the system handles the XML data, and data verification testing methods. For one of the insurance systems we test, we use this methodology:

Step 1: The insurance system integrates all information filled in the front office and generates an XML file. For this step, as quality assurance, we consider the following:

  1. All visible fields are put into the XML file with correct XML node and value.
  2. For some fields in the front office, if the user does not enter anything in that field, the default value of the node will be applied in XML.  For example, in some insurance software, if the user leaves the start date as blank, in XML, the value should be current date and not blank.
  3. Some nodes are only available in the XML file. You can not find the matched field in the front office but sometimes you also need to check if these values are correct. For example, the user enters the birth date of the application in the front office. In XML, there may be a node which is used to represent how long the application will be retired. This number may affect the result of calculation and will be used by other components.
  4. When entering invalid data in front office, no XML is generated.

Step 2: The XML message is used by other components or services and then return a new XML file.

  1. Negative testing: There are restrictions for the value of most of XML nodes.  Usually the restrictions include: number of characters, type of value and business rules. Trying to modify the input XML file to against these restrictions and check whether the proper warning/error message appears and that no output XML file is returned.
  2. Correct output value: Based on the insurance rules of the services, check whether the output XML file contains the correct nodes and values.

Step 3:  The message in the output XML file is shown in the front office software, similar to step1. Verify the different node/value between the input and output XML files.

In general, XML communication is a core method used in many insurance software systems. XML is often used as a format to transfer critical data from the front office to the middle and back office systems. If the data is wrong, the entire system’s integrity and usefulness will decrease significantly. Therefore, as quality assurance, we need to pay special attention to testing the correct XML contents and transfer process.

So, insurance software testing, like any other domain based testing, requires a significant amount of experience to understand the business rules. That knowledge takes time to attain, but without it, its difficult to do the data verification and add value beyond UI testing.