Insurance
Insurance Application Testing Across the Whole Estate
Abhilash
Published On
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
An insurance application estate is every system involved in selling, administering and paying out on a policy: the core policy, billing and claims suite, rating engines, portals, CRM, document composition, payments, finance, third-party data services and the custom code that connects them. Testing the estate means testing the journeys that cross these systems, not each system on its own.
This guide maps the estate layer by layer. For each layer, it covers the platforms insurers commonly run, what tends to change, what tends to break on release, and how to test it. It’s written for Heads of QA, platform owners and architects who need one view of where release risk actually sits.
How Should You Read This Map?
Every system in the estate falls into one of three patterns: configured SaaS, configured self-managed software, or custom code. The pattern decides who controls release timing and what you need to test.
Good testing reaches all three the same way: through the browser, through APIs and through data checks, often in a single journey.
Pattern | Who Controls Release Timing | What the Insurer Tests | Typical Release Risk |
|---|---|---|---|
Configured SaaS (most modern core suites, CRM, payments) | The vendor | Its own configuration, integrations and journeys on each vendor release | Vendor change moves screens, APIs or defaults beneath a working configuration |
Configured self-managed (older core versions, some life platforms) | The insurer, within vendor support windows | Configuration, customisation and upgrade paths | Large, infrequent upgrades that change a lot at once |
Custom built (quote-and-buy sites, microservices, internal apps) | The insurer | Everything, including the contracts with every system it calls | Fast change with no vendor safety net |
One principle runs through the whole map: a heavily configured package behaves like a custom application. The vendor tests its defaults. Nobody tests your product model, your rating tables, your forms and your integrations except you.
Core Policy, Billing and Claims Suites
The core suite is where products are defined, policies are issued, premiums are billed and claims are handled. It changes through vendor releases, product configuration and integration work, and it breaks most often in product rules, endorsements, billing plans and claims workflow.
Test it through end-to-end browser journeys backed by API and data checks.
Common Platforms
Guidewire InsuranceSuite (PolicyCenter, BillingCenter and ClaimCenter, with Jutro digital front ends), Duck Creek Policy, Billing, Claims and Rating, Sapiens CoreSuite and IDITSuite, Majesco P&C Intelligent Core, EIS Suite, Insurity, Socotra, OneShield and Origami Risk. UK insurers and MGAs also run platforms such as SSP Pure and Instanda.
What Changes
Vendor releases arrive on a calendar: Guidewire ships three cloud releases a year and Duck Creek three feature releases a year plus monthly updates. Between releases, product teams add coverages, forms, underwriting questions and lines of business through configuration.
What Breaks
Multi-step submission and quote wizards after interface changes
Underwriting referral rules that stop firing
Endorsements that update the policy but not the premium
Cancellations that calculate the wrong return premium
Billing plans that fail to re-spread after a change
Claims assignment and authority rules
Forms selected for the wrong jurisdiction
How to Test
Journeys follow the full policy lifecycle: submission, quote, bind, issue, endorse, renew, cancel and reinstate. API steps create policies quickly in a known state, so downstream tests for billing, claims and renewal don’t depend on slow UI setup. Data checks confirm premiums, transactions and effective dates. Reusable building blocks for each product keep the pack maintainable across brands.
When a vendor release lands, trace which journeys it affects and review real behaviour changes. Routine interface movement is handled by proposed repairs that a reviewer accepts or rejects, so behaviour changes don’t get lost among cosmetic ones.
Each core platform has its own upgrade quirks. For PolicyCenter, BillingCenter and ClaimCenter, our guide to Guidewire testing covers how to keep regression running through each cloud release.
Duck Creek’s monthly updates bring a different rhythm, which is why Duck Creek testing focuses on keeping configuration and regression in step between feature releases.
Life, Annuity and Pensions Administration
Life and pensions platforms administer contracts that run for decades, so the risk sits in long-dated calculations and in closed books on products no longer sold. Releases break charges, unit allocations, illustrations, retirement options and tax treatment. Test the admin platform and the adviser and member portals against the product terms the business has approved.
Common Platforms
Oracle Insurance Policy Administration (OIPA), Sapiens ALIS, FAST, EXL LifePRO, Equisoft, Majesco L&AH Intelligent Core, V3locity (from Vitech, which Majesco acquired in January 2026), Bravura Sonata and Aquila Heywood Altair, plus the adviser, employer and member portals built around them.
What Changes
Product terms, charging structures, fund ranges, tax rules, regulatory disclosures and, in the UK, connection to the pensions dashboards ecosystem.
What Breaks
Fund switches priced on the wrong date; charges applied to the wrong unit class; illustrations that no longer match product terms; retirement quotes that ignore a protected option; death claim and transfer workflows; closed products whose rules nobody has exercised since the last migration.
How to Test
Draw requirements with expected outcomes from product terms, charging schedules and calculation specifications. Journeys run through member and adviser portals and the admin system, with API and data checks confirming values. Scenario data covers long-dated cases: a policy taken out decades ago, a part-surrender, a switch, a retirement. Actuarial model validation stays with the actuarial function; testing proves the administration platform and portals apply the rules that function approved.
Rating and Pricing Engines
Rating engines turn risk data into a price, and in many insurers the pricing team deploys models more often than engineering deploys code. Releases break factor mapping, rounding, discounts and, in UK home and motor, the relationship between renewal and new business prices. Test price outcomes across channels against the approved rating guide.
Common Platforms
Earnix, WTW Radar, Akur8 and hyperexponential, alongside rating built into core suites such as Duck Creek Rating, Guidewire rating and the enterprise rating Majesco added through its DRC acquisition.
What Changes
Model versions, rating tables, discount rules and competitor-driven adjustments, sometimes weekly.
What Breaks
A model behaves differently in production than in the pricing team's environment; a rating factor is mapped from the wrong field in the policy system; rounding differs between engine and policy system; a channel discount is missed; a timeout triggers a default price; a renewal price drifts above the equivalent new business price.
How to Test
Draw requirements from the rating guide and model release notes, including channel parity and ENBP checks for UK home and motor. Journeys quote the same risk through each channel and compare results. API steps call the rating service directly with known inputs and check outputs. When a new table version arrives, every dependent requirement and test is identified and a pricing analyst approves the updated expectations. See How to Test an Insurance Rating Engine and ICOBS 6B and ENBP testing.
Distribution: Quote-and-Buy, Portals, Price Comparison and Broker Systems
Distribution is where the customer, broker or agent meets the product, and where channel differences turn into pricing and conduct problems. Releases break question sets, channel parity, referrals and payment steps. Test every channel with the same risks, across browsers, and check the data passed between them.
Common Platforms
Custom direct quote-and-buy sites, vendor digital front ends, broker and agent portals, price comparison website integrations, embedded insurance APIs with retail and finance partners, and broker management systems such as Applied Epic, Acturis, Vertafore AMS360 and OpenGI.
What Changes
Question sets, eligibility rules, branding, partner integrations and front-end frameworks.
What Breaks
A new question added to the direct journey but not mapped in the price comparison feed; a referral that works for agents but not brokers; a quote that differs by channel for the same risk; a payment step that fails on one browser; accessibility regressions that exclude customers.
How to Test
Journeys run the same risk through direct, price comparison, broker and partner channels and compare outcomes. API steps exercise the request and response messages exchanged with comparison sites and partners. Execution runs across browser and operating system combinations, including mobile web. Brand and product variations are handled with shared building blocks and data, not copied scripts. See Testing Custom Quote-and-Buy Journeys and Aggregator Feeds.
CRM, Workflow and Service Platforms
CRM and workflow platforms hold the customer view, route work and run service processes such as complaints and vulnerability handling. Releases break data synchronisation with the core system, case routing and service timers. Test these platforms as part of the same journeys that touch the core suite.
Common Platforms
Salesforce, Microsoft Dynamics 365, Pega, Appian and ServiceNow.
What Changes
Vendor seasonal releases, flows and automations built by business teams, and integration mappings to the policy and claims systems.
What Breaks
A policy change that never reaches the customer view; a complaint that is not routed to the right queue or misses its response deadline; a vulnerability flag that does not follow the customer across systems; duplicate customers created by a mapping change.
How to Test
Test these platforms as part of cross-system journeys rather than in isolation. A single journey can make a change in the portal, confirm it in the core system and check it arrived correctly in CRM.
The Claims Ecosystem
Claims rarely live in one system. First notice of loss, coverage checks, fraud scoring, estimating, supplier management and payments are often spread across several platforms. Releases break data handoffs, reserves, authority limits and payments. Test claims end to end, from first notice to settlement.
Common Platforms
Core claims modules, FNOL portals and chat front ends, Snapsheet, Five Sigma, fraud detection platforms such as Shift Technology, estimating platforms, supplier and repair networks, and payment services.
What Changes
Claims rules, authority limits, fraud thresholds, supplier integrations and communication templates.
What Breaks
FNOL fields mapped to the wrong claim attributes; coverage verification that ignores an endorsement; reserves set on an outdated rule; payments released above an adjuster's authority; fraud referrals that stop triggering; claimant updates that never send.
How to Test
Journeys run from first notice through triage, coverage confirmation, reserving, approval and payment, with data-driven variants by peril, coverage and claim size. API and data checks confirm reserves, payment amounts and authority decisions.
Documents and Communications
Documents carry the contract and many of the regulatory disclosures, so a template error is a conduct problem as well as a defect. Releases break template selection, field mapping and delivery. Confirm that the right document is generated from the right data and reaches the customer.
Common Platforms
Smart Communications, Quadient Inspire, OpenText Exstream and DocuSign, plus document services built into core suites.
What Changes
Templates, wordings, jurisdiction-specific forms and regulatory disclosures.
What Breaks
An old template version used after a wording change; a missing or wrong value on a schedule; a renewal notice that omits the previous year's premium, which UK renewal transparency rules require; a document that generates but never sends.
How to Test
Journeys check that each policy event requests the correct document, that the values passed to the composition service match the policy, and that the document is available to the customer or broker in the portal.
Template versions are tied back to the wording or rule that changed them, so the evidence shows which documents each release affected.
Payments, Billing and Finance
Payments and finance close the loop on every policy and claim, and errors here reach customers' bank accounts and the insurer's ledgers. Releases break collections, refunds, instalment recalculation and postings. Test payment journeys in provider sandboxes and check the downstream financial effect.
Common Platforms
Stripe, Adyen, Worldpay, GoCardless for UK Direct Debit, One Inc in the US, premium finance providers, and finance platforms such as SAP, Oracle and Workday. IFRS 17 engines sit downstream.
What Changes
Payment provider APIs, tokenisation, collection schedules, refund rules and chart of accounts mappings.
What Breaks
A failed collection that never triggers the retry or the lapse process; a cancellation refund calculated on the wrong basis; an instalment plan that does not re-spread after a mid-term change; a posting to the wrong ledger account.
How to test it
Journeys take payments through provider test environments, then confirm the billing state and postings with API and data checks. For IFRS 17, the accounting engine's measurement models stay with finance and actuarial teams; QA tests the accuracy of the data flowing into and out of it. See Testing Insurance Payments.
Data and Third-Party Services
Insurers enrich almost every quote and claim with external data, and those calls fail quietly. A timeout or schema change can trigger a default value that changes the price or the decision without any visible error. Test both that the integration works and that its answer was actually used.
Common Services
Credit reference agencies, claims history databases, vehicle data (in the UK, DVLA and Motor Insurance Database checks), property and flood data, address lookup, sanctions screening and identity verification.
What Breaks
Silent fallbacks to defaults; schema changes from the provider; rate limits and unavailable sandboxes in test environments; responses cached longer than intended.
How to Test
In lower environments, journeys run against stubbed or virtualised services with known responses, including timeouts and errors. API steps check the values each service returns. Assertions confirm the enriched value reached the rating or decision step, so a fallback shows up as a failure rather than a quiet pass.
Custom and In-House Applications
Every insurer runs custom software: quote-and-buy front ends, underwriting workbenches, microservices, partner APIs and internal admin apps. These change fastest and have no vendor test pack behind them. Treat them as first-class, with requirements drawn from their specifications and tickets like any other source.
What Breaks
Contracts between services, shared data definitions, error handling and anything nobody documented.
How to Test
Draw requirements from specifications, API definitions and backlog tickets; journeys combine browser steps and API calls; changes to specifications are traced to the tests they affect.
Virtuoso QA's Touchstone tests browser-based applications and APIs. Green-screen mainframe, thick-client desktop systems such as SAP GUI for Windows, and native mobile apps sit outside its scope; where they feed web journeys, Touchstone tests at the API or data boundary, so the journey's outcome is still proven. Mobile web is in scope.
Heavily nested iframes and shadow DOM are workable but higher friction, and some application edge cases need a person to guide the journey.
London Market and Specialty
London market risk moves between brokers, managing agents, carriers and market service providers, so data standards matter as much as screens. With Lloyd's having wound down Blueprint Two in March 2026, attention has shifted to the Core Data Record and ACORD message standards, which the London Market Group's Data Council has extended to claims and delegated authority data.
Common Platforms
Electronic placing platforms such as PPL and Whitespace, managing agent policy and underwriting systems, delegated authority and bordereaux management platforms, and claims systems connected through market messaging.
What Breaks
Data fields that do not map to the Core Data Record; bordereaux that miss or misstate risks; placement data that diverges between firms; claims messages that fail validation.
How to Test
Journeys exercise the browser interfaces of placing, underwriting and bordereaux platforms, and API steps validate the data exchanged against the agreed standard.
The Coverage Matrix: How to Reach Every Layer
Every layer is reached through some combination of browser, API and data check. The matrix shows the usual mix and the evidence each layer contributes to a release.
Layer | Browser Journey | API Step | Data Check | Evidence Produced |
|---|---|---|---|---|
Core policy, billing and claims | Full lifecycle journeys | Fast policy setup and service calls | Premiums, transactions and dates | Product rules proven for each release |
Life and pensions administration | Member and adviser portals | Administration system calls | Values, units and charges | Calculations proven against product terms |
Rating and pricing | Quotes across channels | Direct rating calls | Price outputs and ENBP comparison | Price behaviour proven for each table version |
Distribution | Every web channel and browser | Comparison and partner messages | Channel parity | Conduct-relevant parity proven |
CRM and workflow | Service and case journeys | Sync endpoints | Customer and case state | Service processes proven |
Claims ecosystem | FNOL to settlement | Reserve and payment calls | Amounts and authority | Claims decisions proven |
Documents | Portal availability | Composition requests | Values passed to templates | Correct document for each event |
Payments and finance | Payment steps in sandboxes | Provider and finance calls | Postings and billing state | Money movements proven |
Data and third parties | Indirectly, through journeys | Response checks | Enriched value used | Fallbacks caught |
Custom and in-house | Where there’s a UI | Service calls and responses | Shared data | Specification proven |
Illustrative Example: One Journey Across the Estate
This example is illustrative. It shows how one customer journey crosses eight systems, and how it can be tested as a single, traceable test.
A customer clicks through from a price comparison site to buy home insurance.
Step | System | Test Type | What’s Checked |
|---|---|---|---|
1 | Price comparison handoff | API step | The quote request maps every answer correctly into the insurer’s quote service |
2 | Custom quote-and-buy site | Browser steps | Prefilled answers are correct, an optional cover is added and the price updates |
3 | Rating engine | API step | The rating service returned the price the site displays, with no fallback values |
4 | Core policy system | Browser and data steps | The policy binds with the right premium, cover and effective date |
5 | Payments | Browser step in the GoCardless sandbox, plus a data check | A Direct Debit mandate is set up and the instalment plan is correct |
6 | Documents | API step | The schedule and policy wording requests used current templates and the right values |
7 | CRM | Browser step | The customer and policy appear correctly in Salesforce |
8 | Finance | Data check | The first instalment posts to the right accounts |
When the pricing team issues a new rating table, trace the change to step 3 in this journey and to every other journey that depends on it, and have a pricing analyst approve the updated expectations. The evidence for the release shows the table version, the affected journeys, the approval and the runs.
Test Your Whole Estate, Not Just the Core
Bring one journey that crosses your estate, from the first screen to the last ledger posting, and see Touchstone test it end to end with the evidence attached.
From quote to bind through to first notice of loss and settlement, Virtuoso QA’s insurance testing keeps every layer of the estate in regression, with a record of what each release was tested against.
Interesting Reads
Duck Creek Testing: How to Automate P&C Insurance Application Testing
Test Automation for SAP Commerce Cloud
Guidewire Testing: What to Test, When, and How to Keep Up With the Release Calendar
Microsoft Dynamics 365 Test Automation: Enterprise ERP Testing with Self-Healing AI
Frequently Asked Questions
What systems make up an insurance application estate?
Can one platform test Guidewire, Salesforce and a custom portal in the same test?
How should insurers handle vendor releases on SaaS core platforms?
Does Touchstone test mainframe, desktop or native mobile insurance systems?
Which layer of the estate should an insurer automate first?
