Compared with other insurance products, testing auto insurance software is simple and direct. There are not too many complicated rules. However, auto insurance software testing is very important since most insurance companies sell auto insurance in their product portfolio. Therefore, understanding the rules and important testing points are critical for the testing team.

For most of auto insurance products, there are 4 main sections: personal and contract information, car information, insurance coverage and calculation. For testing auto insurance software, we’ve compiled a list of important business rules and check points:

Personal & Contract Information: This section requires the user (insurance application) to enter the details of the policy holder and the contract such as the name, payment method and effective date. The important check point in this section is the effective date. In different countries, the rules for effective date varies. For example, one of the car insurance products I tested allowed the user to enter 10 days before current date and 6 months after the current date. For testing, a boundary value testing method must be applied not only for positive test cases but also for negative situations.

Car Information: This section includes all car-related information including type, model, license plate…etc. One of the most important fields is to select whether the price of the car includes VAT (Value Added Tax). The reason is that in the final calculation of the insurance fee, the VAT is not included. So in this case, the testing should test both situations: with and without VAT to ensure that the calculation is correct, not to mention that VAT rates will vary across countries.

Insurance Coverage: In this section, the user selects different coverages based on his own needs.  For this section, the testing team should check both specification and business rules carefully. Some kinds of coverage are mandatory and the user must include them. For example, the 3rd party responsibility coverage is mandatory in many countries. In this section, there are also some important rules that require focus. For example, some kinds of coverage are only available when the car fulfills some conditions.  In testing one particular insurance product, I found that the user can select a certain type of coverage only if his car is more than 3 years old, worth up to 3000 euros in value and he does not drive more than 22000 km per year. In this situation, a decision table method may be a good choice to test different combinations. Obviously this was in Europe as we often deal with different units in the US.

Calculation: Even though automobile insurance mostly contains simple products, the calculations can still be complicated. My experience is that for testing the calculation results, the formula for the calculation and the particular parameters and conditions should be explicit in the requirements. We like to create these formulas in an Excel file, and then the entire testing team can use this Excel file as a standard reference (correct/expected results).

As with testing any kind of software, auto insurance software testing requires more than just checking menus and the UI. Luckily, most of us own cars and have applied for auto insurance at one time or another in our lives!