How to test an insurance app
Direct answer
Shipped untested, an insurance app overcharges policyholders at renewal until a complaint reaches the regulator and the carrier pays restitution on every affected policy, and draws a state regulator penalty when the online quoting tool lacks the cybersecurity controls the state regulation requires. 9 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with data integrity and migration testing: a rating data load that maps insurance scores to the wrong tier sends renewals out at premiums that differ from the rates filed with the state.
9 mandatory testsfirst: data integrity and migration testing
What counts as an insurance app
An insurance app here is a consumer product on web, iOS and Android for quoting, binding, paying premiums, filing claims and managing policies, with a rating engine fed by filed rate tables and third-party scores. It covers the instant-quote form, the agent quoting portal, rating data loads, premium payments and refunds, and models used in pricing or claims triage. Comparison sites that only pass leads to carriers, health benefits administration and reinsurance systems are out of scope.
Adjacent product types not covered here
- lending platform: A lending platform scores applicants for credit, so adverse action notices and credit bureau files replace filed rate tables and claims model drift.
- accounting and invoicing SaaS: An accounting and invoicing SaaS calculates tax on invoices for small businesses, so bank feed duplicates and VAT filing replace premium rating and licence number exposure.
- buy now pay later service: A buy now pay later service collects instalments for merchant purchases, so refunds that leave instalments running replace renewal premiums that drift from filed rates.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Money leaves or fails to arrive money-loss | money | primary | Policyholders are overcharged at renewal until a complaint reaches the regulator, and the carrier pays restitution on every affected policy. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | The state insurance regulator penalises the carrier because the online quoting tool lacked the controls its cybersecurity regulation requires, and adopting states expect insurers to test pricing models for unfair discrimination (NAIC bulletin). | |
| Personal or sensitive data exposed data-breach | data | primary | The instant-quote form prefills a driver's license number for any name and birth date typed in, so attackers harvest licence numbers without buying a policy. | |
| Records silently wrong data-corruption | data | primary | A data load maps insurance scores to the wrong rating tier, and renewals go out at premiums that differ from the rates filed with the state. | |
| Users or operators act on wrong numbers wrong-decisions | trust | primary | A claims triage or pricing model drifts after a data change, and adjusters keep approving or denying claims on its scores without noticing. |
Mandatory tests (9)
Step 1: release smoke tests
Why:money-loss
Done when: After each release, a test customer gets a quote, binds a policy, pays the first premium and sees the policy documents in the app.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: data integrity and migration testing
Why:data-corruptionmoney-losswrong-decisions
Done when: After each rating data load, a reconciliation report shows no renewal whose premium differs from a recalculation with the filed rates.
Tool class: data validation. Who usually runs it: QA engineer.
Step 3: unit tests
Done when: For a reviewed set of test drivers and homes, the rating engine returns the same premium as the filed rate tables, factor by factor.
Tool class: unit framework. Who usually runs it: developer.
Step 4: payment and money-flow testing
Why:money-loss
Done when: In the sandbox, a mid-term cancellation refunds the unearned premium once to the original card, and a declined renewal payment does not mark the policy as paid.
Tool class: API client. Who usually runs it: QA engineer.
Step 5: penetration testing
Why:data-breachregulatory-penalty
Done when: An external tester cannot extract licence numbers from the quote or agent tools, and the agent portal refuses login without a second factor.
Tool class: proxy. Who usually runs it: external lab.
Step 6: compliance checks
Why:regulatory-penaltywrong-decisions
Done when: A reviewer finds a dated record of bias and accuracy testing for each model used in pricing or claims, and a sign-off before each model change.
Tool class: test management. Who usually runs it: product manager.
Step 7: integration tests
Why:data-corruption
Done when: An insurance score or vehicle record returned by the data vendor lands in the policy record with the same value and tier the vendor sent.
Tool class: API client. Who usually runs it: developer.
Step 8: end-to-end functional tests
Why:data-breach
Done when: Typing a stranger's name and birth date into the quote form returns no driver's license number or household driver details on any screen or response.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 9: security scanning
Why:data-breach
Done when: The latest scan of the public quote tool, the agent portal and their APIs shows no open finding that exposes licence numbers or policy data.
Tool class: DAST scanner. Who usually runs it: security specialist.
Recommended and optional tests
contract testsrecommended
Becomes mandatory when more than one data vendor feeds the rating engine.
regression suiterecommended
Becomes mandatory when rate filings change more than once a year.
accessibility testingrecommended
Becomes mandatory when an accessibility complaint is received or a public-sector contract requires it.
resilience and failure testingrecommended
Becomes mandatory when quotes are issued automatically without underwriter review.
exploratory testingoptional
Sessions around endorsements, mid-term changes and claims on lapsed policies may find premium or coverage states scripted cases miss.
device and browser compatibilityoptional
Claim photo upload depends on camera and file handling that differs across phones.
Not needed and why
Not needed for risk control: no attached risk depends on comprehension testing. Becomes recommended when quote abandonment is a tracked goal.
Not needed: no outage under load is recorded for this type. Becomes recommended when a catastrophe event can drive a surge of claims filed in the app.
Not needed: policies are sold in one language and jurisdiction. Becomes recommended when policy documents are issued in a second language.
Order of work
First release
- release smoke tests: As a test customer, get a quote, bind a policy, pay the first premium and confirm the policy documents appear in the app.
- data integrity and migration testing: After the rating data load, run the reconciliation report and confirm no renewal premium differs from a recalculation with the filed rates.
- unit tests: Rate the reviewed set of test drivers and homes and compare each premium with the filed rate tables, factor by factor.
- payment and money-flow testing: In the sandbox, cancel a policy mid-term and confirm the unearned premium is refunded once to the original card, then decline a renewal payment and confirm the policy is not marked paid.
- penetration testing: Have an external tester try to extract licence numbers from the quote and agent tools and log in to the agent portal without a second factor.
- compliance checks: Confirm a dated record of bias and accuracy testing exists for each model used in pricing or claims, with a sign-off before each model change.
- integration tests: Request an insurance score and a vehicle record from the data vendor's test service and confirm the policy record holds the same value and tier the vendor sent.
- end-to-end functional tests: Type a stranger's name and birth date into the quote form and confirm no driver's license number or household driver details appear on any screen or response.
- security scanning: Scan the public quote tool, the agent portal and their APIs and close every finding that exposes licence numbers or policy data.
Ongoing cadence
- release smoke tests: After every release of the quote, bind or payment flow.
- data integrity and migration testing: After each rating data load from files or vendors.
- unit tests: After each rate filing change reaches the rating engine.
- compliance checks: Before each change to a model used in pricing or claims.
- integration tests: When a score or vehicle record vendor changes its file or API version.
- end-to-end functional tests: After each change to quote form prefill from motor vehicle or third-party records.
- contract tests: Before each rating load once more than one data vendor feeds the rating engine.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of insurance app (web, ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
unit tests
payment and money-flow testing
- Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
- Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for insurance app has the same 9 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the insurance app is accepted when a test customer can quote, bind, pay the first premium and see policy documents in the app. After each rating data load, the reconciliation report shows no renewal premium that differs from a recalculation with the filed rates. Typing a stranger's name and birth date into the quote form returns no driver's license number or household driver details.
Brief
# Test brief: insurance app Product type: insurance app. Quote, bind, claim and policy management for consumers. Risk map and evidence: https://howtotestaproduct.com/how-to-test/insurtech-app/ Printable checklist: https://howtotestaproduct.com/checklists/insurtech-app/ Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: money-loss). Tool class: browser automation. Usually run by: QA engineer. Done when: After each release, a test customer gets a quote, binds a policy, pays the first premium and sees the policy documents in the app. 2. data integrity and migration testing (risks: data-corruption, money-loss, wrong-decisions). Tool class: data validation. Usually run by: QA engineer. Done when: After each rating data load, a reconciliation report shows no renewal whose premium differs from a recalculation with the filed rates. 3. unit tests (risks: data-corruption, money-loss). Tool class: unit framework. Usually run by: developer. Done when: For a reviewed set of test drivers and homes, the rating engine returns the same premium as the filed rate tables, factor by factor. 4. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer. Done when: In the sandbox, a mid-term cancellation refunds the unearned premium once to the original card, and a declined renewal payment does not mark the policy as paid. 5. penetration testing (risks: data-breach, regulatory-penalty). Tool class: proxy. Usually run by: external lab. Done when: An external tester cannot extract licence numbers from the quote or agent tools, and the agent portal refuses login without a second factor. 6. compliance checks (risks: regulatory-penalty, wrong-decisions). Tool class: test management. Usually run by: product manager. Done when: A reviewer finds a dated record of bias and accuracy testing for each model used in pricing or claims, and a sign-off before each model change. 7. integration tests (risks: data-corruption). Tool class: API client. Usually run by: developer. Done when: An insurance score or vehicle record returned by the data vendor lands in the policy record with the same value and tier the vendor sent. 8. end-to-end functional tests (risks: data-breach). Tool class: browser automation. Usually run by: QA engineer. Done when: Typing a stranger's name and birth date into the quote form returns no driver's license number or household driver details on any screen or response. 9. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The latest scan of the public quote tool, the agent portal and their APIs shows no open finding that exposes licence numbers or policy data. Acceptance criteria wording: A release of the insurance app is accepted when a test customer can quote, bind, pay the first premium and see policy documents in the app. After each rating data load, the reconciliation report shows no renewal premium that differs from a recalculation with the filed rates. Typing a stranger's name and birth date into the quote form returns no driver's license number or household driver details. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing an insurance app
What testing does an insurance app need?
9 tests are mandatory, from the quote-to-bind smoke test and rating data reconciliation to penetration testing of the agent portal and quote prefill checks. Each is tied to one of the 5 risks in the map, such as renewals priced off the filed rates or licence numbers harvested through the instant-quote form. Contract, regression, accessibility and resilience tests are recommended, each with the event that makes it mandatory.
What testing is required for an insurance app as a financial product?
Compliance checks are mandatory while models support underwriting, pricing or claims decisions, requiring a dated record of bias and accuracy testing and a sign-off before each model change. Penetration testing is mandatory while the carrier is subject to a state insurance cybersecurity regulation. The map cites a state regulator penalty for the online quoting tool and the NAIC model bulletin for model testing.
Which tests in a vendor test plan for an insurance app are not needed?
Performance testing is not needed until a catastrophe event can drive a surge of claims filed in the app. Localization is not needed while policies are sold in one language and jurisdiction. Usability testing is not needed for risk control while no attached risk depends on how customers understand the quote, until quote abandonment is a tracked goal.
When is test automation worth it for an insurance app?
Unit tests are mandatory while premiums come from the app's rating engine, comparing each test premium with the filed rate tables factor by factor. The regression suite becomes mandatory when rate filings change more than once a year, keeping renewal premiums for a fixed set of past policies unchanged unless a filed rate change says otherwise.
Evidence
ev-0095court-or-fineprimary
Official Order of the Texas Commissioner of Insurance No. 2026-10013 (Occidental Fire & Casualty Company of North Carolina), Texas Department of Insurance
Through review of a consumer complaint, the department discovered that a data loading error resulted in Occidental charging rates different than those on file.
Supports data-corruption and money-loss for an insurance app: a data translation error in insurance scores fed the rating engine, renewals were charged rates different from the filed rates, and the insurer owed restitution.
published 2026-07-08 · verified 2026-10-07
ev-0096court-or-fineprimary
Official Order of the Texas Commissioner of Insurance No. 2026-10039 (Germania Companies), Texas Department of Insurance
Supports data-corruption and money-loss for an insurance app: a data loading error made the rating system use incorrect data to calculate auto renewal premiums, producing overcharges and undercharges that required restitution.
published 2026-07-21 · verified 2026-10-07
ev-0093court-or-fineprimary
Attorney General James and DFS Superintendent Harris Secure [amount] from Auto Insurance Companies over Data Breaches, New York State Department of Financial Services
Hackers were able to obtain New Yorkers' driver's license numbers from GEICO's publicly-facing website because GEICO failed to protect this information on the website's back end.
Supports data-breach and regulatory-penalty for an insurance app: attackers pulled driver's license numbers from public online quoting tools and the insurers were penalised under the state cybersecurity regulation.
published 2024-11-25 · verified 2026-10-07
ev-0097standardprimary
NAIC Model Bulletin: Use of Artificial Intelligence Systems by Insurers, National Association of Insurance Commissioners
These standards require, at a minimum, that decisions made by Insurers are not inaccurate, arbitrary, capricious, or unfairly discriminatory.
Supports wrong-decisions for an insurance app: insurers using AI or predictive models in underwriting, pricing or claims are expected to test for errors, bias and model drift, and adopting states hold them to it.
published 2023-12-04 · verified 2026-10-07
ev-0094court-or-fineprimary
Attorney General James Secures [amount] from Car Insurance Companies Over Data Breaches, New York State Attorney General
Supports data-breach for an insurance app: the instant-quote prefill feature returned driver's license numbers for anyone whose name and birth date an attacker typed in, a second enforcement action on the same failure pattern.
published 2025-10-14 · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.