How to Test Insurance Software: A QA Guide for InsurTech Teams

Written by: Chief Technology Officer

Dmitry Reznik

Posted: 02.11.2026

20 min read

A rating engine that applies last quarter's factor table to 10,000 renewals. A claims system that pays out on a coverage limit that was endorsed down three months ago. A disclosure that never renders for policies issued in one state. None of these are "crashes" – the software runs, the logs are green, and the money is already gone. That is what makes insurance software testing different from testing a typical web product: the most expensive defects are correct-looking numbers that are wrong.

The scale of what is at stake is not abstract. Accenture estimates that poor claims experiences could put up to $170 billion of global premiums at risk over five years, with 30% of dissatisfied claimants already having switched carriers. Claims leakage – paying more than the policy actually owes – runs at an industry benchmark of about 3% of claims cost, and has been measured as high as 25% in some portfolios. A meaningful share of that leakage is software: rules applied wrongly, integrations silently failing, effective dates mishandled.

This guide covers how to test the systems that carry that risk – rating and underwriting engines, policy administration, claims, billing, portals and the integrations between them – and how to automate enough of it that every rate filing or rule change does not turn into a two-week manual regression. It is written for QA leads and engineering managers at insurers, MGAs and insurtech vendors; if you need a partner for the work, our insurance software testing services page describes how we scope it.

Why insurance software is harder to test than a typical web app

Insurance software fails differently because its complexity lives in data and rules rather than in UI. Five properties drive most of the testing effort:

• Rules-heavy logic. Rating, underwriting and claims adjudication are large tables of rules that vary by product, territory, coverage and – critically – by date. A rate filed in March applies to policies effective from 1 April but not to a renewal quoted on 31 March. Every rule has an effective-dated version history, and the engine must pick the right one.

• Long-lived data. A policy issued in 2019 must still process correctly after five years of releases. Test data that only contains this year's products will never find the bug in last year's endorsement path.

• Many external dependencies. Credit bureaus, motor vehicle records, property and geospatial data, medical data for life and health, payment processors, document generation, e-signature, reinsurance bordereaux, regulator filings. Most of these have no reliable sandbox.

• Compliance embedded in logic. Disclosures, consent, rate filings and fair-treatment rules are not a separate "compliance module" – they are conditions scattered across quote, bind and claims flows. A test that only checks the happy path will pass while the regulator-required text is missing for one product in one state.

• Legacy cores next to new front ends. Guidewire, Duck Creek, Majesco, Sapiens or an in-house core from the 2000s sits behind a React portal and a mobile app. Industry analysis attributes 5–20% of premium leakage to inefficiencies in exactly these legacy-plus-wrapper architectures.

Banking apps share some of this – rules, integrations, regulation – and much of what we describe in our fintech software testing work transfers. The difference is the time dimension. A payment is right or wrong at the moment it happens; a policy has to be right at every date across its life. If you are coming from a fintech background, the complete fintech QA guide is the natural companion to this article.

The insurance software landscape: what you will actually be testing

Testing insurtech software means testing six or seven distinct systems that pretend to be one product. Knowing which one you are in determines what "correct" means.

Policy administration system (PAS). The system of record for a policy: who is insured, for what, at what premium, from when to when. Every change is a transaction with a date, and the PAS must be able to reconstruct the policy as it stood on any past date.

Quote and rating engine. Takes risk inputs (age, location, property characteristics, claims history) and produces a premium using filed rate tables and factors. Often a separate component with its own release cycle.

Underwriting workbench and rules engine. Decides whether to accept a risk, on what terms, and when to refer to a human. Rules reference external data (credit score, MVR, property records) and change frequently.

Claims management system. First notice of loss (FNOL) through coverage verification, reserving, adjudication, payment, subrogation and recovery. The place where most money leaves the company.

Billing and payments. Instalment plans, premium finance, direct debit, card payments, commission to agents, refunds on cancellation.

Agent, broker and customer portals. The surfaces where quotes are run, documents downloaded, claims filed and payments made. Usually the newest code and the most frequently released.

Embedded insurance APIs. Insurance sold inside someone else's product – travel insurance in a booking flow, device cover at checkout, auto insurance in a car-sharing app. The insurer's logic runs behind a partner's UI, and the partner's test environment is rarely yours.

Insurtech investment keeps flowing into these layers – $4.25 billion globally in 2024 according to Gallagher Re, with AI-centred companies taking 34.6% of deals – which means more new code touching old cores, and more integration seams to test.

How to test a rating engine and underwriting rules

Rating engine testing is a data problem, not a UI problem: the goal is to prove that for every combination of inputs the engine returns the filed premium, on the right effective date, with the right rounding. Five practices cover most of it.

1. Build a rating test matrix. Dimensions: product × territory × coverage × risk factors × effective date. You cannot test every cell, so apply pairwise or orthogonal-array selection to get coverage of every two-factor interaction, then add every boundary (minimum and maximum age, the first and last day of a rate version, the highest deductible).

2. Use golden-file testing. The actuarial team already has the truth: the approved rate table, usually a spreadsheet. Export expected premiums for the matrix from that source and compare engine output row by row. Any difference is either an engine defect or a spreadsheet defect – both are worth finding before customers do.

3. Test the date logic explicitly. Rate changes effective at midnight; a quote created on 31 March and bound on 1 April; a 12-month policy straddling a mid-term rate change; a renewal that must use the renewal rate version, not the new-business one. These scenarios produce the costliest production defects and are almost never covered by UI tests.

4. Check rounding, currency and tax. Per-coverage rounding versus total rounding, minimum premiums, taxes and levies that vary by state or country, pro-rata and short-rate calculations on cancellation. Document the expected rounding rule in the test, not just the expected number.

5. Automate the matrix and run it on every filing. A rate filing is a release. The matrix should run in CI in minutes so that a new filing or a factor-table change triggers a full regression without anyone scheduling it.

A rating test case looks like this:

Underwriting rules follow the same approach: a decision matrix (accept / refer / decline, with terms) checked against the documented rule set, plus explicit tests for referral thresholds and for what happens when an external data source times out – the engine should refer, not silently accept.

Testing policy administration: lifecycle and endorsements

Policy administration testing is lifecycle testing: quote → bind → issue → endorse → renew → cancel → reinstate, and every transition is a scenario with money and dates attached.

• Lifecycle transitions. Each transition changes premium, documents, billing schedule and coverage. Test every allowed transition and every disallowed one (reinstating a policy cancelled for fraud should fail; backdating an endorsement before inception should fail).

• Mid-term endorsements. Adding a driver, changing a deductible, moving house. The pro-rata premium adjustment must use the number of days remaining, the correct rate version, and produce a credit or debit on the billing schedule. Test endorsements that cross a rate-change date and endorsements on policies with instalment plans already partially paid.

• Document generation. Declarations, schedules, certificates, state-mandated notices. Testing that "a PDF was produced" is not enough: assert the data on the document (named insureds, limits, effective dates, premium) against the policy record, and assert that mandatory text appears for the product and jurisdiction. Snapshot-compare documents between releases.

• Premium payments and billing. Instalment plans, failed payments and dunning, refunds on cancellation, agent commission. Card and bank payments bring PCI DSS into scope and need the same end-to-end validation we apply in payment application testing: amount, currency, idempotency on retries, and reconciliation between the billing system and the processor.

• Data migration. Moving off a legacy core is where PAS testing gets expensive. Reconcile record counts by product and status, map every field, and reconcile financial totals (written premium, unearned premium, outstanding balances) to the cent between source and target. Then run the rating matrix against migrated policies to confirm they renew at the right premium.

Testing claims management end to end

Claims testing has to prove that the system pays what the policy owes – no more, no less – and that it does so within the service levels the regulator and the customer expect. In a market where 31% of claimants report dissatisfaction and 60% of those cite settlement speed, the workflow timing is a test requirement, not a nice-to-have.

FNOL across channels. Web, mobile, call centre, partner API, email ingestion. The same loss reported through each channel must create the same claim with the same required fields; test the validation differences and the duplicate-detection logic.

Coverage verification as of the loss date. The claim must be evaluated against the policy as it stood on the date of loss – not today. A deductible endorsed up last week does not apply to a loss three weeks ago. This is the single most important claims test and the most frequently missed.

Reserves, payments and recoveries. Initial reserve rules, reserve adjustments, partial and final payments, multiple payees (claimant, repairer, lienholder), subrogation and salvage recoveries. Reconcile every claim's financial history to the general ledger.

Fraud and triage rules. Scoring rules route suspicious claims to investigators; with insurance fraud estimated at $308.6 billion a year in the US alone, these rules carry real money. Test both directions: known fraud patterns are flagged, and legitimate claims are not stalled. Our guide to testing fraud detection systems in financial applications covers the technique in depth.

SLA and workflow timing. Acknowledgement, assignment, decision and payment deadlines are often statutory. Test the timers, the escalations and the reporting that proves compliance.

Integration testing: where insurance platforms break most often

Integration failures cause more production incidents in insurance platforms than core logic defects, because the core logic is tested and the third-party behaviour is assumed. Treat every external dependency as something that will be slow, down or wrong, and test what the platform does then.

Third-party data providers. Credit bureaus, DMV/MVR, property and geospatial data, flood and catastrophe models, medical information bureaus. Test: timeouts and retries, partial responses, schema changes, stale data flags, and the underwriting decision when data is unavailable (refer, never auto-accept).

Payment gateways and premium finance. Authorisation, capture, refund, chargeback, instalment scheduling, and reconciliation files. Test idempotency – a retried payment must not charge twice – and the dunning path when a payment fails on day 1, day 7 and day 30.

E-signature, document management and print vendors. Envelope creation, signing order, completed-document retrieval, and what happens when a customer signs after the quote has expired.

Reinsurance and bordereaux reporting. Cession calculations, treaty attachment points, and the monthly bordereaux files that reinsurers reconcile against. Errors here surface quarters later, so test them at source.

Contract testing and mocking. Most providers have no sandbox that behaves like production. Record real responses, build contract tests that fail when the provider's schema drifts, and use mocks to simulate the failure modes you cannot trigger on demand. The approach is covered step by step in API testing for fintech applications.

Compliance and security testing for insurance applications

Compliance testing for insurance means tracing every regulatory requirement to a test case that proves the software enforces it – the auditor will ask for exactly that mapping. Security testing matters more here than in most industries: IBM's 2024 report puts the average breach cost for financial services, insurers included, at $6.08 million, 22% above the cross-industry average, with breaches taking an average of 168 days to identify.

GDPR and CCPA/CPRA. Consent capture and withdrawal, data subject access and deletion requests across PAS, claims and document stores, retention schedules, and lawful-basis logic for underwriting data. GDPR fines reach €20 million or 4% of global turnover, whichever is higher. The validation checklist in GDPR testing for financial applications applies directly.

PCI DSS v4.0. If premiums are paid by card, the billing path is in scope. PCI DSS v4.0 became the only active standard in March 2024 and its future-dated requirements became mandatory on 31 March 2025. Our step-by-step guide to PCI DSS v4.0 compliance testing covers what QA must verify.

SOC 2 and ISO 27001. Enterprise insurers and reinsurers expect vendors to hold them; the evidence they ask for includes test documentation, access-control testing and change-management records.

DORA. The EU's Digital Operational Resilience Act has applied to insurers and reinsurers since 17 January 2025, and it treats testing as a regulated activity: resilience testing programmes, third-party ICT risk, incident reporting. If you operate in the EU, DORA compliance for insurers shapes the test strategy, not just the audit.

Regional insurance regulation. Rate filings must match what the engine charges; mandatory disclosures and notices must appear for the right product and jurisdiction; fair-treatment and anti-discrimination rules constrain which factors may be used in rating and how. Build a requirements-traceability matrix: each regulation → requirement → test case → last result.

Security. Authentication strength, session management, role-based authorisation (a producer must not see another agency's book; a customer must not see another policyholder's claim), API authorisation on every endpoint, and data masking in all non-production environments. Do not mention or test for HIPAA unless the product is health insurance – it is a frequent copy-paste error in insurance QA plans.

Performance testing for insurance platforms

Insurance load is scheduled and spiky, so performance testing must model the calendar, not just a flat concurrency number.

Peak scenarios. Open enrolment and 1 January renewals, month-end and year-end billing runs, a hurricane or flood that generates 50,000 FNOLs in 48 hours, a marketing campaign that triples quote volume, and the regulatory reporting deadline that makes every underwriter run the same report at 4 p.m.

Batch and online together. Renewal batches, billing cycles and bordereaux generation run overnight; portals and APIs run during the day. Test the overlap – the batch that runs long into business hours is a classic incident.

What to measure. Quote latency at the 95th percentile (a quote over three seconds loses the lead), rating-engine throughput, batch window completion against the SLA, document-generation throughput, and database contention on the policy table during renewal runs.

Test automation strategy for insurtech teams

Insurance QA automation pays back fastest where the input space is large and the rules change often: rating, policy lifecycle regression and integrations. It pays back slowest where judgement matters: new product configuration and document review.

Automate first:

• The rating matrix (data-driven, API-level, no UI).
• Policy lifecycle regression: a scripted journey from quote to cancellation for every live product.
• Integration contract tests for every third party.
• Claims financial reconciliation.
• Smoke tests on every portal after each deployment.

Keep manual or exploratory:

• Configuring and validating a new product before its rules are stable.
• Document content and layout review for new jurisdictions.
• Agent and adjuster workflow usability.
• Accessibility with screen readers.

Test data. Synthetic policyholders generated to cover the rating matrix; effective-dated data sets so that "a policy issued in 2019" exists in every environment; masked production extracts only where synthetic data cannot reproduce the distribution. Never real PII in non-production.

Tooling. Playwright for portals; Postman or REST Assured for APIs and the rating engine; a data-driven framework (pytest or TestNG parameterised from the actuarial export) for matrices; k6 or JMeter for peaks; visual and content diff for documents; all wired into CI so that a rate filing, rule change or core patch triggers the full regression automatically. Shipping releases safely on this kind of platform is the subject of regression testing for fintech.

This is not theoretical. On rules-heavy financial platforms with the same characteristics – calculation engines, effective dates, external data – DeviQA cut full regression from two days to three hours for The Mortgage Office and built more than 4,000 automated UI and API tests for ChargeAfter, a point-of-sale financing platform whose credit-decision logic is structurally similar to underwriting. The same architecture applies to a PAS or a rating engine.

Insurance software testing checklist

Rating and underwriting

• Rating matrix covers every product, territory, coverage and boundary value, compared against the actuarial golden file.
• Every rate-version boundary date is tested for quote, bind and renewal.
• Rounding, minimum premium, taxes and levies are asserted per jurisdiction.
• Underwriting referral and decline thresholds are tested, including behaviour when external data is unavailable.

Policy lifecycle

• Every allowed and disallowed lifecycle transition has a test.
• Mid-term endorsements produce the correct pro-rata adjustment and billing change, including across a rate change.
• Generated documents are asserted for data and mandatory text, not just existence.
• Migrated policies reconcile in count and financial totals and re-rate correctly at renewal.

Claims

• Coverage is verified against the policy as of the loss date.
• Reserve, payment, subrogation and recovery flows reconcile to the ledger.
• Fraud rules flag known patterns and do not stall legitimate claims.
• Statutory timers and escalations are tested.

Integrations

• Every third party has contract tests and failure-mode tests (timeout, partial, schema drift).
• Payment retries are idempotent; dunning paths are tested at each stage.
• Bordereaux and reinsurance calculations are verified at source.

Compliance and security

• A traceability matrix links each regulation to test cases and results.
• GDPR/CCPA requests work across every data store.
• Card payment paths meet PCI DSS v4.0 requirements.
• Role-based access is tested for every role pair; no PII in non-production.

Performance

• Load tests model renewal, billing, catastrophe and campaign peaks.
• Batch and online load are tested concurrently.
• 95th-percentile quote latency and batch window completion are tracked per release.

Core insurance system upgrade: how QA fits in

A core upgrade – replacing or re-platforming the PAS, claims or billing system – is the highest-risk project an insurer runs, and QA is the control that makes it survivable. Four kinds of testing carry most of the weight.

Migration testing reconciles every policy, claim and financial balance between the old and new systems, by product and status, to the cent. Parallel running processes the same transactions through both systems for one or more cycles and compares outputs – premiums, documents, payments – before cut-over. Regression automation on the new core, built before migration, proves that the rating matrix, lifecycle journeys and integrations behave identically. User acceptance testing with underwriters, adjusters and billing staff validates the workflows that no automated test understands.

What types of testing platforms are used for core insurance upgrade QA?

Typically four, used together: a data reconciliation platform (SQL-based comparison or a dedicated migration tool) for counts and balances; an API and data-driven test framework (Postman, REST Assured, pytest) for rating and lifecycle regression; a UI automation tool (Playwright, Selenium) for portal smoke and workflow tests; and a load-testing platform (k6, JMeter) for the renewal and billing peaks on the new infrastructure. Test management and traceability (TestRail, Xray, Zephyr) ties them to regulatory requirements for the audit trail.

Conclusion

Most production defects in insurance software come from three places: rating and underwriting logic applied with the wrong version or date, integrations that fail quietly, and effective-dated data that was never in the test set. A rating matrix compared against the actuarial truth, contract tests on every third party, and test data that spans the real age of your book will catch the majority of them – and automating all three means the next rate filing is a CI run, not a release freeze.

If you would like to see how this works on your platform, talk to us about a free proof of concept on one flow – quote-to-bind or FNOL-to-payout – before any commitment.

FAQ

What is insurance software testing?

Insurance software testing is the verification of the systems that quote, issue, bill, service and pay insurance policies — rating engines, policy administration, claims, billing, portals and their integrations — against filed rates, policy terms, regulation and service levels. Its distinguishing feature is effective-dated logic: the software must be correct not only today but for every date across a policy's life.

What types of testing platforms are used for core insurance upgrade QA?

Data reconciliation tooling for migration, an API-level data-driven framework for rating and lifecycle regression, UI automation for portals, a load-testing platform for peaks, and a test management tool that traces every test to a regulatory requirement.

How is testing insurtech software different from testing banking apps?

Both are rules-heavy and regulated. Insurance adds the time dimension — rate versions, effective dates, policies that must be reconstructed as of any past date — and a claims process where the system decides how much money to pay out based on a contract written months or years earlier.

How do you test a rating engine?

Build a matrix of inputs across product, territory, coverage, risk factors and effective date; export expected premiums from the actuarial rate tables; compare engine output row by row; test every rate-version boundary date and rounding rule; automate the matrix to run on every filing.

Which regulations apply to insurance application testing?

GDPR or CCPA/CPRA for personal data, PCI DSS v4.0 for card payments, SOC 2 and ISO 27001 as enterprise expectations, DORA for EU insurers since January 2025, and the state or national insurance regulations covering rate filings, disclosures and fair treatment. Each should trace to specific test cases.

How long does it take to automate regression for a policy administration system?

For a single-line PAS with a stable rating engine, a usable automated regression suite (rating matrix, lifecycle journeys, integration contracts, portal smoke) typically takes eight to twelve weeks to build and then runs in under an hour. Multi-line, multi-jurisdiction platforms take longer, mainly because of test-data preparation.

About the author

Dmitry Reznik

Chief Technology Officer

Dmitry Reznik is the Chief Technology Officer and co-founder at DeviQA, bringing deep technical expertise across software architecture, implementation, and long-term system operation.