Policy Administration & Lifecycle Testing
A policy is not a record that sits still. It moves through a defined set of states — quoted, bound, issued, endorsed, renewed, cancelled — and every transition can corrupt the data the contract depends on. This lesson teaches you to test that lifecycle.
1 The Hook
Kahu Insurance, a fictional NZ general insurer, sold a house-and-contents policy to a Wellington customer. At quote, the customer declared a sum insured of $850,000 on the dwelling. They bound the cover, paid, and the policy was issued. Everything looked right.
Three months later the customer added a sleepout to the policy — a mid-term endorsement to raise the contents cover. The system processed the endorsement, took the extra premium, and confirmed the change. What nobody noticed was that the endorsement screen had silently reset the dwelling sum insured to a default of $500,000, because the endorsement form did not carry the original value forward and re-saved the whole policy.
The policy sat quietly under-insured for eight months. Then a storm damaged the roof and a chimney. The customer claimed, expecting cover up to $850,000, and the assessor read $500,000 off the current policy record. The customer was told they were under-insured and the settlement was cut. The customer had never asked to reduce their cover. A test gap, not a customer choice, had quietly stripped $350,000 of protection.
Here is the lesson hidden in that story. The team had tested that a quote produced a price, that binding took payment, that an endorsement applied a change. Each transition passed on its own. What no test checked was that data the customer never touched survived the transition unchanged. The dangerous defects in policy administration are not in any single screen — they are in what a state change does to the fields you were not looking at.
2 The Rule
A policy is the contract, and the policy data is the contract’s terms. Every lifecycle transition — quote to bind, endorse, renew, cancel — must change exactly what it intends and leave every other field untouched. Test the transition for what it changes and, just as hard, for what it must not change. An endorsement that quietly alters a field the customer never touched is a contract changed without consent.
3 The Analogy
Editing one clause of a signed tenancy agreement.
A tenant and landlord agree to add a clause allowing a pet. The right way to do that is to amend the one clause and leave the rest of the signed agreement exactly as it was — the rent, the bond, the term, all unchanged. Imagine instead that adding the pet clause silently reset the rent to a blank template default. The tenant agreed to one small change and walked away with a different contract. They would be furious, and rightly so.
A policy endorsement is the same. The customer asks to change one term. A correct endorsement touches that term and nothing else. Kahu Insurance changed the pet clause and reset the rent — the endorsement applied the requested change and quietly rewrote a field the customer never agreed to. A lifecycle tester is the person who checks that an amendment amends one thing, not the whole agreement.
4 The Policy Lifecycle
A policy moves through a defined sequence of stages. A tester must know each one, because each has its own rules and its own failure modes.
Quote. The customer supplies risk details and the system returns a price. Nothing is bound yet. A quote can be saved, recalled, and converted — or it can expire. The key property is that a quote is not cover: no risk has been accepted.
Bind. The customer accepts the quote and the insurer agrees to carry the risk. Cover now exists from the agreed start date. Binding is the moment the promise becomes real, so the data captured at quote must carry through to the bound policy exactly.
Issue. The policy document — the schedule and wording — is produced and sent. This is the artefact the customer keeps and a claim is read against. Issue must reflect the bound terms precisely; a mismatch between the issued schedule and the held policy data is a defect with legal weight.
Endorse. A mid-term change to a live policy — raising a sum insured, adding a driver, changing an address. An endorsement adjusts the premium pro-rata for the remaining term and must alter only the agreed fields. This is the Kahu Insurance failure point.
Renew. At the end of the term the policy is offered again for a new period, usually re-rated against current rate tables. Renewal must carry the policy’s history and data forward intact while applying the new terms and price. Data continuity across renewal is a lesson of its own (Lesson 5).
Cancel. The policy is ended before or at the end of its term, by the customer or the insurer. Cancellation must stop cover from the right date, calculate any pro-rata refund correctly, and leave a clear record — cover after a cancellation date is a claim the insurer should not be paying.
5 The Policy as a State Machine
The cleanest way to reason about a policy is as a state machine: a set of states, and the transitions allowed between them. This gives you two whole families of tests for free.
Valid transitions must work. Quoted can become bound. Bound can become issued. Issued can be endorsed, renewed, or cancelled. Each allowed move must succeed and land the policy in the correct new state with the correct data.
Invalid transitions must be refused. This is where the real bugs hide. A cancelled policy must not be endorsable. An expired quote must not be bindable without re-quoting. A policy cannot be issued before it is bound. A policy cannot be renewed after it has been cancelled. Every state has moves that should be impossible, and the system must say no to all of them.
Bound → can be issued, can be cancelled. Cover exists from the start date.
Issued / In force → can be endorsed, renewed, cancelled, claimed against.
Lapsed → premium unpaid past grace; cover suspended. Reinstatement rules apply.
Cancelled → terminal for this term. Cannot be endorsed or claimed against for losses after the cancel date.
Drawing the state machine out turns vague “test the policy module” into a checkable list: every allowed transition is a positive test, every disallowed transition is a negative test, and the negative tests are where systems most often fail.
6 Policy Data Integrity
The policy record is the single source of truth for what is covered, for how much, and on what terms. If a field is wrong, every downstream decision — the premium, the claim, the renewal — inherits the error. So a lifecycle tester treats the data itself as a test target.
- Carry-forward integrity: values the customer set at quote must appear unchanged at bind, issue, and after any unrelated endorsement — the exact Kahu Insurance gap.
- Effective dating: a change has a date from which it applies. A test must check that cover, premium, and any refund all use the correct effective date, not the date the change was keyed.
- Schedule-versus-record consistency: the issued policy schedule must match the held policy data exactly — sum insured, excess, named insured, address, cover type.
- Monetary precision: premiums, sums insured, and excesses must hold the right precision and rounding. A cent lost per policy across a book is a real reconciliation break (Lesson 5).
- Referential integrity: the policy links to a customer, a product, a rate table version. Those links must stay valid through every transition — an endorsement must not orphan the policy from its product definition.
7 What to Test in the Lifecycle
The practical checklist for a policy-administration tester:
- Every valid transition: quote → bind → issue, plus endorse, renew, and cancel from in-force — each lands the correct state with the correct data.
- Every invalid transition: endorse a cancelled policy, bind an expired quote, claim against an unbound policy — each is refused cleanly with a clear message, not a silent partial action.
- Carry-forward on endorsement: change one field and assert every untouched field is identical before and after.
- Effective dating and pro-rata: a mid-term change applies from the right date and adjusts premium for the remaining term correctly.
- Cancellation correctness: cover stops on the right date, the pro-rata refund is correct, and no claim succeeds for a loss after the cancel date.
- Schedule generation: the issued document reflects the bound terms exactly, with no rounding or default substitution.
- Concurrency and partial failure: if a transition fails part-way (payment taken, endorsement not saved), the policy is left in a consistent state, not a half-changed one.
8 Building Lifecycle Test Cases
A strong lifecycle test case names the transition, states the starting state, and asserts on both what must change and what must not change — not just that the screen said success.
Here is a worked test case written to catch the exact Kahu Insurance bug:
Transition: Endorsement (mid-term change) on an in-force house policy
Risk category: Silent overwrite of an untouched field (under-insurance)
Pre-conditions: In-force policy; dwelling sum insured $850,000; contents $60,000;
full pre-change policy record snapshotted.
Action: Endorse the policy to raise contents sum insured to $75,000;
apply and confirm. Snapshot the policy record again.
Expected result: 1) Contents sum insured changes from $60,000 to $75,000.
2) Dwelling sum insured remains $850,000 (UNCHANGED).
3) Every other field identical to the pre-change snapshot.
4) Premium adjusted pro-rata for the remaining term only.
Evidence required: Before/after full policy-record diff; issued endorsement schedule;
pro-rata premium calculation.
Traceability: Risk R-02 (endorsement overwrites an untouched sum insured).
Result: [Pass / Fail] — any unintended field change listed.
Notice what makes this catch the Hook bug: the expected result asserts an explicit UNCHANGED on the dwelling value and demands a full before/after diff, so a silent reset cannot pass. The case names the transition and the starting state, and it traces to a numbered risk. Those properties are the difference between a real lifecycle test case and “check the endorsement works.”
9 Common Mistakes
🚫 Testing only what a transition changes, never what it must not change
Why it happens: The requirement describes the change, so the test follows the change and stops there.
The fix: The Kahu Insurance trap lives in untouched fields. Snapshot the full policy record before and after every transition and assert that only the intended fields differ. Silent overwrites are the most damaging policy-admin defect and they only show up in the diff.
🚫 Testing only valid transitions and skipping the negative paths
Why it happens: Positive flows are in the acceptance criteria; the impossible moves are not written down.
The fix: Draw the state machine and test every disallowed transition — endorsing a cancelled policy, binding an expired quote, claiming on an unbound policy. The system must refuse each cleanly. These negative paths are where policy systems most often leak.
🚫 Confusing the date keyed with the effective date
Why it happens: The system records when a change was entered, and that feels like when it applies.
The fix: Cover, premium, and refunds run off the effective date, which is often back- or forward-dated relative to the keying date. Test that a mid-term change applies from its effective date, not the day it was typed, or the pro-rata and the cover period will be wrong.
🚫 Assuming the issued schedule matches the held policy data
Why it happens: Both come from the same system, so they feel guaranteed to agree.
The fix: The schedule is generated through its own template and rounding, and it is the document a claim is read against. Compare the issued schedule field by field against the held policy record — sum insured, excess, named insured, cover type — because a mismatch is a contract dispute waiting to happen.
10 Now You Try
Three graded exercises across the policy lifecycle. Write your answer, run it for AI feedback, then compare to the model answer.
Read the description of a fictional vehicle-insurance policy-admin flow below. Identify 3 lifecycle risks that could corrupt policy data, allow an impossible action, or apply a change from the wrong date, and name the part of the lifecycle each touches (bind, endorse, renew, cancel, data integrity).
When a customer endorses their policy to add a second driver, the endorsement screen reloads the whole policy and re-saves it; the agreed excess is re-defaulted from the product template rather than carried forward. Endorsements apply from the date the change is keyed, not the date the customer asked for. A cancelled policy can still be reopened and endorsed if you navigate directly to its endorsement URL. The issued policy schedule is generated from a separate template that rounds the sum insured to the nearest hundred dollars.
List 3 lifecycle risks and the part each touches:
Show model answer
There are at least four real risks here; any three well-explained earns full marks. 1. Silent overwrite of the excess on endorsement — adding a driver re-defaults the agreed excess from the template instead of carrying it forward, so a field the customer never touched changes. Lifecycle part: endorse / data integrity. Impact: the customer's agreed excess is silently altered — the Kahu Insurance class of defect. Fix: carry forward all untouched fields; diff before/after. 2. Change applied from the keyed date, not the effective date — endorsements take effect when typed, not when the customer asked. Lifecycle part: endorse / effective dating. Impact: cover and pro-rata premium run from the wrong date. Fix: apply from the effective date and test the pro-rata against it. 3. Cancelled policy can be endorsed via direct URL — an invalid transition is reachable. Lifecycle part: cancel / state machine. Impact: a terminated policy is changed and could be treated as in force. Fix: enforce state rules server-side, not just by hiding the UI. Bonus: schedule rounds the sum insured to the nearest $100 — the issued document no longer matches the held policy data; a claim read against the schedule could be wrong. Fix: compare schedule to record field by field. The trap: each transition "works" on its own screen — the defects are in untouched fields, wrong dates, and impossible states reachable around the UI.
The endorsement test case below is too shallow to catch a silent overwrite. Rewrite it to assert on both what changes and what must not change, with these fields: Test ID, Transition, Risk category, Pre-conditions, Action, Expected result, Evidence required, Traceability. Use a fictional NZ contents-insurance endorsement as the context.
“Raise the contents sum insured. Check the new value is saved. Pass if it shows the new amount.”
Rewrite as a full lifecycle test case:
Show model answer
Test ID: POL-END-018 Transition: Endorsement (mid-term change) on an in-force contents policy Risk category: Silent overwrite of an untouched field (under-insurance) Pre-conditions: In-force contents policy; contents sum insured $60,000; excess $400; named insured and address captured; full pre-change policy record snapshotted. Action: Endorse to raise contents sum insured to $80,000 with an effective date of today; apply and confirm; snapshot the policy record again. Expected result: 1) Contents sum insured changes from $60,000 to $80,000. 2) Excess remains $400 UNCHANGED. 3) Named insured, address, cover type, and every other field identical to the pre-change snapshot. 4) Premium adjusted pro-rata from the effective date for the remaining term only. 5) Issued endorsement schedule matches the updated record exactly. Evidence required: Before/after full policy-record diff showing only the sum insured changed; pro-rata premium calculation tied to the effective date; issued endorsement schedule compared field by field. Traceability: Risk register R-02 (endorsement overwrites an untouched field) and R-04 (effective dating). What makes it strong: it asserts an explicit UNCHANGED and a full diff so a silent reset fails, ties pro-rata to the effective date, and compares the schedule to the record. The original asserted only the new value and would pass even while quietly resetting the excess.
Design a state-transition test plan of 5 test cases for a fictional NZ house-and-contents policy, covering both valid and invalid transitions. Each case needs at least: an ID, what it verifies, an acceptance criterion, and the evidence required. Cover quote→bind, bind→issue, a valid endorsement, an invalid transition (endorse a cancelled policy), and cancellation with a pro-rata refund.
Show model answer
POL-01 | Verifies: quote converts to bound cover with data carried forward | Acceptance criteria: all quote risk details (sum insured, excess, named insured, address) appear unchanged on the bound policy; cover starts on the agreed date | Evidence required: quote record vs bound record diff; cover start date POL-02 | Verifies: a bound policy is issued with a schedule matching the record | Acceptance criteria: issued schedule matches the held policy data field by field; 0 mismatches, no rounding substitution | Evidence required: issued schedule vs policy record field-by-field comparison POL-03 | Verifies: a valid mid-term endorsement changes only the intended field | Acceptance criteria: only the endorsed field differs in a before/after diff; premium adjusted pro-rata from the effective date | Evidence required: before/after policy-record diff; pro-rata calculation POL-04 | Verifies: an invalid transition is refused — a cancelled policy cannot be endorsed | Acceptance criteria: the endorsement is rejected cleanly (including via direct URL); policy stays cancelled; 0 fields change | Evidence required: rejection response; policy record unchanged; server-side enforcement evidence POL-05 | Verifies: cancellation stops cover and refunds pro-rata correctly | Acceptance criteria: cover ends on the cancel date; pro-rata refund equals unused premium for the remaining term; no claim succeeds for a loss after the cancel date | Evidence required: cover end date; pro-rata refund calculation; post-cancel claim attempt rejected Strong plans: each case is specific, has a measurable criterion, names concrete evidence, and together they cover a valid bind (POL-01), issue/schedule consistency (POL-02), a valid endorsement (POL-03), an invalid transition (POL-04), and cancellation with refund (POL-05). Weak plans say "check the policy lifecycle works" five times — that is the difference being marked.
11 Self-Check
Click each question to reveal the answer.
Q1: Why must a lifecycle test assert on fields the transition does not intend to change?
Because the most damaging policy-admin defects are silent overwrites — an endorsement that quietly resets a field the customer never touched, like the Kahu Insurance dwelling sum insured. Asserting only the intended change passes while the contract is altered without consent. Snapshot the full record before and after and prove only the intended fields differ.
Q2: What two families of test does treating a policy as a state machine give you?
Valid transitions that must work (quote→bind, bind→issue, endorse, renew, cancel) and invalid transitions that must be refused (endorse a cancelled policy, bind an expired quote, claim on an unbound policy). The negative paths are where policy systems most often leak, so the state machine turns “test the module” into a concrete list.
Q3: Why does the difference between the keyed date and the effective date matter?
Cover, premium, and any refund all run off the effective date, which is often back- or forward-dated from the day a change was entered. If the system uses the keying date, the cover period and the pro-rata premium are wrong. Test that mid-term changes apply from their effective date, not the date they were typed.
Q4: Why compare the issued schedule against the held policy record?
The schedule is generated through its own template and rounding, and it is the document a claim is read against. If it diverges from the held data — a rounded sum insured, a wrong excess — the customer holds one set of terms while the system holds another. That mismatch is a contract dispute, so compare them field by field.
Q5: What is the single highest-value lifecycle test, and why?
A before-and-after full-record diff around every transition: snapshot, change, snapshot, assert only intended fields differ. It is cheap to automate and it directly catches the silent-overwrite class of defect — the most common and most damaging policy-admin failure — while producing exactly the evidence that proves data integrity held.
12 Interview Prep
Real questions asked in NZ QA interviews for insurance roles. Read the model answers, then practise your own version.
“Walk me through how you would test a mid-term endorsement.”
I’d start by naming the transition and the exact set of fields the endorsement is allowed to change. Then I snapshot the full policy record, apply the change, and snapshot again. I assert two things: the intended field changed correctly, and every other field is identical — that diff is what catches a silent overwrite of an untouched sum insured or excess. I check the change applies from the effective date, not the keyed date, and that the premium is adjusted pro-rata for the remaining term only. Finally I compare the issued endorsement schedule against the held record field by field, because the schedule is what a claim is read against.
“A customer says their cover was reduced but they never asked for it. What is your first hypothesis?”
My first hypothesis is a silent overwrite during an unrelated transition — an endorsement or renewal that re-saved the whole policy and re-defaulted a field the customer never touched, resetting a sum insured to a template default. I’d reproduce it by snapshotting the record, performing the same change the customer made, and diffing — if a field outside the intended change moved, that is the defect. I’d also check whether the issued schedule and the held record diverged, because that mismatch can hide the change from everyone until a claim.
“How would you test that impossible policy actions are actually impossible?”
I’d draw the policy state machine and list every disallowed transition — endorsing a cancelled policy, binding an expired quote, claiming on an unbound policy, renewing after cancellation. Then I test each one, and crucially I test it past the UI, because hiding a button is not the same as enforcing a rule. I’d hit the endorsement endpoint directly for a cancelled policy and confirm it is refused server-side with the policy left untouched. The negative paths are where these systems leak, so I treat them as first-class tests, not edge cases.