Platform / Test Automation / Enterprise Applications / Insurity
Insurity test automation from the UAT test cases your business already wrote.
Insurity’s P&C core platforms — policy administration, billing, claims, workers’ comp, and specialty suites — are configured differently at every carrier and MGA, updated on Insurity’s cloud schedule, and judged by people who know the book of business rather than a test framework. Spec2RunAI, the test executor inside Spec2TestAI, runs the manual test cases your business already has against Insurity as written — no object library, no scripting, no conversion project — and ends every run with an evidence report a business owner can sign. We tuned it against a live Insurity environment, in partnership with Insurity.
AgileAI Labs is a sponsor, and a joint presenter with Insurity.
Tuesday, October 6, 9:30–10:15 am — “How to Put Guardrails Around AI-Driven Testing, Quality Agents, and Self-Healing Automation.” Kurt Bedocs, VP, Quality, Insurity, and Missy Trumpler, CEO, AgileAI Labs, on where AI-driven testing creates real value for carriers and MGAs, where guardrails matter most, and what to look for as AI-driven quality becomes embedded in insurance technology platforms. The guardrails in that title are the ones on this site: healing that cannot change what a test verifies, a verification-coverage number on every run, and an AI provenance record a reviewer can read.
Four things that make Insurity testing different from testing a web app you built.
Configured, not coded
Rating, forms, underwriting rules, billing plans, and workflow are set by configuration, by Insurity, your implementation partner, and your own analysts. The vendor tested the product; the risk sits in your configuration, and only your people can say whether a result is right.
Released on Insurity’s calendar
Cloud platforms ship on the vendor’s schedule, and each release is a regression cycle for every carrier on the platform. A test suite that costs a week of repair per release is not a tooling problem; it is a standing line in the budget.
Screens built for underwriters, not for scripts
Multi-step policy and claim workflows, list views, modal pickers, date and currency fields, and generated element identifiers — the markup your automation would bind to is the vendor’s, and it changes without your commit.
The people who know the answer cannot write the script
Whether a quote rated correctly, a reserve posted to the right coverage, or a delinquency triggered on schedule is a judgment for underwriters, adjusters, and billing analysts. When automation needs an engineer to translate their test, the translation becomes the bottleneck and the evidence loses its author.
The journeys that matter, across the Insurity suite.
Written the way your testers already write them. The executor resolves each step against the live screen, so a changed panel, label, or wizard step is absorbed rather than repaired.
Policy administration
New business through quote, underwriting review, and issue; endorsements, renewals, cancellations, and reinstatements; rating checks against expected premium — across Insurity’s policy administration products for commercial, specialty, and workers’ comp lines.
Billing
Account setup, invoicing, payment plans, direct and agency bill, delinquency and cancellation workflows, commissions, and disbursements.
Claims and workers’ comp
First notice of loss through reserving, assignment, and payment; recovery; notes and documents; and the compliance-heavy workflows specific to workers’ comp.
Portals and integrations
Agent and policyholder journeys that land in the core suite, and the cross-system checks — a policy that must appear in billing, a payment that must appear on the claim — that single-application tests cannot see.
Insurity’s cloud environments reachable from the internet run from our cloud executor; self-hosted deployments run through the local agent — the same executor installed inside your network, outbound HTTPS only. How a run executes →
Tuned against a live Insurity environment, not a screenshot.
Working with Insurity, we ran real test cases through a live environment and tuned the executor until the control patterns the suite uses — list views, detail panels, multi-step workflows, modal pickers, typeahead fields, date and currency inputs — resolved reliably from the plain-English step alone. The same tuning program covers Guidewire PolicyCenter, so carriers running both get one executor and one evidence format.
No object library to build or buy
There is no Insurity pack, no element map, and no specialist role to staff. The executor reads the screen the way an adjuster does and acts on what it sees. Pages your partner configured are handled the same way as standard ones.
Proven steps replay deterministically
The first run interprets each step against the live screen. Afterward, selector memory replays proven steps in about two seconds without a model call, re-validated against the step’s intent before each action — which keeps a full regression affordable on every release.
Healing that cannot move the goalposts
Autonomous Tuning rewrites how a failed step runs against the live screen, never what it verifies. Assertion Lock keeps the expected premium, the reserve amount, and the invoice total exactly as the tester wrote them, and the report proves it.
Evidence a business owner can sign
Every run ends in a Run Evidence Report: verification coverage per step, failures classified as application defect, test defect, environment, or data, comparison with the previous run, an AI provenance appendix, and a PDF with signature lines for QA review and business sign-off.
Three ways to automate a core suite, described plainly.
Where the first two are right, we say so: a partner framework your team maintains comfortably has no migration risk, and accelerator packs reach batch processes and integration layers that a UI executor does not. Our three-year cost model shows the crossover in your own numbers, including the case where an in-house team wins.
What Insurity customers ask us first.
Which Insurity products does Spec2RunAI work with?
The executor is not built around any one product. It was tuned against a live Insurity environment so that the control patterns the suite uses — multi-step workflows, list views, panels, pickers, typeahead and date fields — resolve from the plain-English step, and the same approach carries across policy administration, billing, claims, and workers’ comp screens. Show us the workflow you run and we will run it.
Do we need an Insurity plugin, accelerator, or object library?
No. There is nothing to install in Insurity and no element map to maintain when a page is configured or reconfigured. The executor reads the interface the way a person does and acts on what it sees.
What happens when Insurity ships a release?
Run the suite in your pre-production environment during the release window. Steps re-resolve against the new screens; where a label or layout changed, Autonomous Tuning rewrites how the step runs and the evidence report records the rewrite beside the original wording, with the expected result unchanged. Failures arrive classified, so a real regression in your rating or billing rules is separated from a cosmetic change before anyone opens the application.
Can our underwriters, adjusters, and BAs write and run the tests?
Yes. The test cases they already wrote for UAT — in Jira, Zephyr, qTest, Excel, or Word — run as written, and new ones are written the same way. No syntax to learn and no engineering queue between the person who knows the business rule and the result.
Does it run against Insurity’s cloud and against self-hosted deployments?
Both. Cloud environments reachable from the internet run from our cloud executor, one isolated agent per test case. Self-hosted deployments run through the local agent, the same executor installed inside your network with outbound HTTPS only — no inbound ports, no VPN.
What about test data: policies, claims, accounts?
Tests reference data the way testers do — a policy number, an insured name, a claim in a given state — and the platform can provision synthetic test data through GenRocket Data Connect where production-like records are needed without production data. Data-caused failures are classified as such in the report, separately from application defects.
Bring us a quote, a claim, and an invoice.
Send ten of your existing Insurity UAT test cases, untouched. We will run them against your environment and hand you the evidence report. At the conference, find us at the sponsor tables or after the Tuesday session.