Insurance software testing
Insurance software is a set of promises about money, written down, that have to hold for years and be recalculable on any date in between. That is a different testing problem from most software, and it is not solved by clicking through a quote form.
We are an independent testing company. We have tested other people's software since 2018, we did not write yours, and we have no development contract to protect by staying quiet about what we find. An embedded team can be working on your product in about two weeks, and those first two weeks are free if you are not happy with what we deliver.
What actually breaks in insurance software
Effective dating. A policy is a state machine that moves through time, and most defects live in the gap between the date something happened and the date it takes effect. Mid-term adjustments, backdated endorsements, pro-rata refunds, cancellations with a reinstatement three weeks later. A test suite that only ever runs against today's date cannot see any of this. We test with the clock moved.
Rating. Rate tables are versioned by effective date, and a rate change deployed against the wrong version reprices business you have already written. Testing a rating engine means testing the table, the date the table applies from, and what happens to a quote saved yesterday and bound tomorrow. The arithmetic is the easy half.
Claims. First notification, reserving, payment, recovery and subrogation, salvage. Reserve movements land in the general ledger, so a claims defect is an accounting defect one hop later. The path that gets tested is the claim that gets paid. The paths that do not get tested are partial settlement, reopening a closed claim, and a payment that fails after the reserve has already moved.
Documents. Schedules, certificates, renewal notices. The single most visible defect class in this industry is a correct policy with a wrong document, because the document is the only thing the policyholder reads. Generating ten thousand PDFs where one figure is wrong is a complaint file, not a bug ticket.
Integration. ACORD messages between broker and carrier, aggregator and comparison feeds with hard latency budgets, bordereaux from delegated authority. These fail quietly and on a schedule, which means they fail at the end of the month when nobody is watching.
Test automation for insurance
Insurance is an unusually good fit for automation and an unusually bad fit for the way automation is normally done here.
The good fit: rate changes are frequent, and every one of them risks business already on the books. A regression suite that reprices a fixed sample of real policy shapes before and after a rate deployment, and fails on any movement nobody asked for, is worth more than any number of UI tests. That suite is data driven by construction. You build it once and feed it a matrix.
The bad fit: quote and bind journeys are long, branchy and rendered by portals that change quarterly, so UI-first automation in this market rots faster than anywhere else. We push as much as possible down to the rating service and the policy API, where the contract is stable, and keep the browser tests to the handful of journeys where the browser is the thing under test. Where we do drive a UI, we use Flows, our own recorder, which repairs its own selectors when a portal is redesigned.
More on both approaches: test automation, API testing, regression testing.
Test data, which is the part everyone underestimates
Policy data is personal data, and in health, life and some liability lines it is special category data. Copying production into a test environment solves the realism problem and creates a much larger one.
So the first thing we usually build is not a test. It is a way to generate policy and claim data that is shaped like yours without being yours. Real distributions, real edge shapes, synthetic people. If that already exists in your organisation, we use it and say so. If it does not, we will tell you in week one that it is the prerequisite, because testing rating against four sample policies tells you almost nothing about a book of two hundred thousand.
Regulatory work we can and cannot help with
Solvency II reporting and IFRS 17 measurement are data pipelines with an audience of regulators. They can be tested the way any pipeline is tested: reconcile the output to an independently computed figure, and fail on any difference. We do that part.
We are not actuaries. We test that the software computes what your actuary specified. We do not validate the specification. Those are different jobs and in some jurisdictions the second one is a regulated activity.
Our certifications, and what each one is actually worth, are set out at certifications. ISO/IEC 27001:2022 is the relevant one here, because it governs how we handle your data, your credentials and your environments.
When we are the wrong choice
We would rather say this on the page than on the third call.
If you are running a packaged policy administration platform and what you need is someone who already knows your Guidewire or Duck Creek configuration on day one, a platform-specialist consultancy will beat us for the first two months. We learn systems quickly and we will not pretend to arrive knowing your configuration.
If you need a signature on a regulatory attestation, we cannot give you one. We are an independent testing company, not a registered auditor.
If nobody inside your business can state what the correct premium is for a given risk, testing cannot establish it. That is a specification problem, and it has to be solved before a test has anything to assert against. We will say so rather than bill for a month of finding out.
And outsourcing does not work at all where the contract requires staff on site or nationals only, which happens in some public-sector and reinsurance arrangements.
How we start, and what it costs
Two weeks, no contract. We embed, learn the product, write tests and file real bugs against your actual software. If you are not happy with what we deliver in those two weeks, you do not pay for them. You decide whether to carry on, and we invoice from week three. We do this because nobody can judge testing quality from a proposal, and every QA company's proposal reads the same.
After that, $25 to $45 an hour depending on seniority, commitment length and the mix of manual, automation and specialist work. Longer commitments move down the range. Every engineer on your product has shipped commercial releases before.
Included at no licence cost: BugBoard for test management, Flows for automation that heals its own selectors, Auditi for GDPR, WCAG and FDA auditing, BetterFlow so you can see where the hours went, and our AI Security Toolkit. We built all five because the off the shelf versions did not keep up with us.
Our engineers are in Cluj-Napoca, Romania, on GMT+2 and GMT+3 in summer. That covers the European working day and overlaps the start of the US East Coast day.
Talk to us
Tell us what you underwrite, how often you deploy, and what went wrong most recently. We will tell you whether this helps, and if it does not, we will tell you that instead.