Why User Acceptance Testing Matters
A rate release is ready for user acceptance testing (UAT) when its intended behavior can be checked against a clear specification. UAT tests representative rating situations using the data and transactions that users expect to handle, then compares the resulting system premiums with independently calculated expected premiums. The goal is not merely to confirm that the system produces a number. It is to establish that the right rating rules were applied to the right inputs, including at boundaries and when an exception applies.
The earlier material on translating rate indications into production specifications and integrating rating changes across policy systems provides the operational context. UAT focuses on whether the implemented release behaves as the approved specification requires. A successful test suite should include ordinary cases, edge cases, discounts, exceptions, and regression cases for behavior that should remain unchanged. Each test should have enough information to reproduce the result: input values, applicable rules, calculation steps, expected output, observed output, and a pass or fail decision.
Turn Rating Rules Into Test Cases
Begin with an approved rule, not with a screen or a convenient sample quote. For each rule, identify the rating input, its valid values, the factor or decision it selects, any eligibility condition, and the expected premium effect. Then write test cases that distinguish correct behavior from plausible implementation errors.
For example, a factor that applies when payroll is “up to and including $100,000” has a different boundary from one that applies when payroll is “less than $100,000.” Testing only a value well below the threshold will not reveal whether the equality condition was implemented correctly. A useful boundary set includes a value just below the threshold, the threshold itself, and a value just above it. The exact values should respect the precision and units of the input field.
A practical test set usually includes the following kinds of cases:
- Representative risks: ordinary combinations of rating variables that exercise common rating paths.
- Boundary values: values immediately below, at, and above thresholds, limits, or tier changes.
- Discount cases: eligible, ineligible, and combined discounts, including any cap or precedence rule.
- Exceptions: missing, expired, invalid, or conflicting data that should trigger a defined outcome.
- Regression cases: stable scenarios whose results should not change under the release.
The test specification should say what happens when an input is missing or invalid. It might require rejection, a referral, or a defined default, but a tester should not infer which outcome is intended. Likewise, if discounts are capped or applied in a prescribed order, record that rule explicitly. Otherwise a tester and a system may produce different premiums while each appears internally consistent.
Expected Premiums and a Short Derivation
For a simple multiplicative rating calculation, assume the approved specification gives a base premium \(P_0\) and rating factors \(r_1,\ldots,r_k\). Assume each factor applies to the premium produced by the preceding step, there are no additional adjustments, and the final premium is rounded to cents using the stated rounding convention. Under these assumptions, the expected unrounded premium is the base premium multiplied by all applicable factors.
This product follows from successive application. After the first factor, the premium is \(P_0r_1\). Applying the second factor gives \((P_0r_1)r_2=P_0r_1r_2\). Repeating this argument for each factor gives \(P_0\prod_{j=1}^{k}r_j\). This justification applies only when the specification calls for multiplicative factors. A fixed surcharge, a discount cap, a minimum premium, or a rule that changes the order of operations must be handled as a separate stated step.
An expected result should be calculated independently from the production system being tested. Record intermediate values so a difference can be traced to an input, factor, eligibility decision, operation order, or rounding step. Before testing begins, define the comparison rule. For example, a specification may require exact agreement to the cent, or it may allow a stated tolerance. A tolerance should not excuse a wrong rating decision: a case that used an ineligible discount can fail even if its premium happens to lie within a broad dollar tolerance.
Write the approved condition, factor, discount, or exception in testable terms, including units and whether boundary values are included.
Select ordinary cases and values that make likely mistakes produce a different result, such as just above and below a threshold.
Show the calculation sequence, retain precision as specified, and round only at the documented output step.
Compare each system result with its expected result, apply the stated tolerance, and record any discrepancy with enough detail to reproduce it.
Worked Example: Testing Both Sides of a Payroll Boundary
A hypothetical commercial policy has a base premium of $600. Its approved specification assigns a payroll factor of 0.95 when annual payroll is at most $100,000 and 1.00 when payroll is greater than $100,000. The other factors are territory 1.25, class 0.90, limit 1.00, and deductible 1.00. Assume all listed factors multiply the base premium and the output is rounded to cents. Calculate the expected premium at payrolls of $100,000 and $100,000.01.
Method. Apply the stated factors to the base premium, changing only the payroll factor between the two cases. This is a paired boundary test: it checks both equality and the first valid value above the threshold.
At $100,000 payroll. The phrase “at most $100,000” includes equality, so the payroll factor is 0.95. The intermediate calculations are:
The expected premium is $641.25.
At $100,000.01 payroll. This value is greater than $100,000, so the payroll factor is 1.00. The other factors are unchanged:
The expected premium is $675.00. The increase is $675.00 − $641.25 = $33.75, consistent with replacing the factor 0.95 by 1.00 on the $675.00 premium before the payroll factor.
Common mistake avoided. Treating “at most $100,000” as “less than $100,000” assigns the 1.00 factor at exactly $100,000 and produces $675.00 there. The boundary case must instead produce $641.25. The pair of results is a check of the rule, not just a check that the system accepts both payroll values.
Check. The factors other than payroll multiply to $600 × 1.25 × 0.90 = $675.00. Applying 0.95 gives $641.25, while applying 1.00 leaves $675.00, confirming both premiums.
Testing Discounts and Exceptions
A discount test must verify both the premium arithmetic and the eligibility decision. A system can calculate a percentage correctly but apply it to a risk that does not qualify. Conversely, it can identify eligibility correctly but combine multiple discounts in the wrong way. Include cases where only one discount applies, where several apply together, and where a required condition is not met.
The expected calculation must follow the specified combination rule. Additive discounts, sequential discounts, and capped discounts are not interchangeable. For example, two additive discounts of 8% and 5% produce a 13% reduction before any cap; sequential discounts produce the product of their remaining-premium percentages. The test should also establish whether a discount is excluded when supporting evidence is missing or expired.
Worked Example: Verifying a Discount Cap and an Expired-Document Exception
A hypothetical policy has a base premium of $1,250. An eligible multi-policy discount is 8%, and a protective-device discount is 5% only when the inspection document is current. The specification adds eligible discounts and caps their combined reduction at 12%. The final premium cannot be less than $1,000. Assume discounts are calculated from the base premium, the minimum is applied afterward, and the final amount is rounded to cents. Find the expected premium for (a) a current document and (b) an expired document.
Method. Determine eligibility first, add the eligible percentages, apply the cap, calculate the discounted amount, and then check the minimum premium.
(a) Current document. Both discounts apply. Their sum is 8% + 5% = 13%, which exceeds the 12% cap. The allowed reduction is therefore 12%, or \(0.12(1,250)=\$150.00\). The premium before the minimum check is $1,250.00 − $150.00 = $1,100.00. Since $1,100.00 is greater than the $1,000 minimum, the expected premium is $1,100.00.
(b) Expired document. The protective-device discount is ineligible, so only the 8% multi-policy discount applies. The reduction is \(0.08(1,250)=\$100.00\). The premium before the minimum check is $1,250.00 − $100.00 = $1,150.00, which exceeds the minimum. The expected premium is $1,150.00.
Common mistake avoided. Multiplying sequentially by 0.92 and 0.95 would give $1,250(0.92)(0.95) = $1,092.50 for the current-document case, contrary to the additive-and-capped rule. Applying the device discount despite an expired document would also incorrectly produce the capped result of $1,100.00 for case (b).
Check. The current-document premium reflects the maximum permitted 12% reduction, and the expired-document premium reflects only the eligible 8% reduction. Both results exceed the minimum, so the floor does not change either answer.
Regression Tests and Premium Reconciliation
A release can correctly change one factor and still inadvertently alter another rating path. Regression cases make that risk visible by holding stable inputs constant and checking that their expected results remain stable under the new release. These should include important unchanged combinations and, where relevant, representative policy transactions. The expected result comes from the approved specification for that case, not from an assumption that every premium must change or remain the same.
Reconcile results at the individual test-case level before looking at totals. For each case, calculate the dollar difference as system premium minus expected premium. A positive difference means the system result is higher; a negative difference means it is lower. If the comparison rule includes a tolerance, apply it to each required unit of comparison, such as each policy or each coverage, as specified.
An aggregate total is useful as an additional check, but it cannot replace row-level checks. One overcharge can offset one undercharge, leaving the aggregate unchanged. A reconciliation report should therefore show both case-level differences and any requested total, with a clear pass or fail result for every test.
Worked Example: Finding Offset Errors in a Regression Batch
A hypothetical regression batch uses a base premium of $500 and the multiplicative rule \(P=500 \times\) territory factor \(\times\) class factor \(\times\) deductible factor. All factors are applied without intermediate rounding; premiums are reported to cents. Three cases should produce the following results from the approved specification:
- Case A: territory 1.00, class 1.00, deductible 1.00.
- Case B: territory 1.20, class 1.10, deductible 1.00.
- Case C: territory 1.20, class 1.00, deductible 1.00.
The system returns $500.00 for A, $630.00 for B, and $630.00 for C. Determine whether the batch passes if agreement to the cent is required.
Method. Calculate each expected premium independently, compare each case with its system result, and then compare totals. Agreement to the cent means any nonzero case-level difference is a failure.
Case A. Expected premium: $500 × 1.00 × 1.00 × 1.00 = $500.00. Difference: $500.00 − $500.00 = $0.00.
Case B. Expected premium: $500 × 1.20 = $600.00; $600.00 × 1.10 = $660.00. The system difference is $630.00 − $660.00 = −$30.00.
Case C. Expected premium: $500 × 1.20 = $600.00; multiplying by 1.00 and 1.00 leaves $600.00. The system difference is $630.00 − $600.00 = +$30.00.
The expected total is $500.00 + $660.00 + $600.00 = $1,760.00. The system total is $500.00 + $630.00 + $630.00 = $1,760.00. Although the totals match, cases B and C each fail the cent-level comparison, so the batch fails.
Common mistake avoided. Checking only the overall premium total would miss the offsetting $30 undercharge and $30 overcharge. The row-level results must be investigated; the matching total does not establish that either case was rated correctly.
Check. The two nonzero differences sum to −$30.00 + $30.00 = $0.00, which explains why the aggregate agrees despite two failed cases.
Acceptance Criteria and Common Traps
Before executing tests, state what counts as a pass. If premiums must agree exactly to the cent, say so. If a tolerance is allowed, define its size, whether it is absolute or relative, and whether it applies per policy, per coverage, or to an aggregate. Do not let an unspecified tolerance become a substitute for a decision.
UAT is most useful when expected values and failure conditions are recorded before comparing results. If a mismatch appears, retain the inputs and calculation trace, identify the rule that should have applied, and record the observed system result. That creates a reproducible defect report rather than an unstructured statement that “the quote looks wrong.” The test suite should be rerun after a correction, including the failed case and relevant regression cases.
- Testing only typical values: ordinary cases can miss an inclusive-boundary defect. Include exact threshold values and nearby values.
- Testing arithmetic but not eligibility: verify that discounts and exceptions apply only when their conditions are met.
- Using system output as the expected value: calculate the expected premium from the approved rules independently.
- Reconciling only totals: inspect each required case because positive and negative differences can cancel.
- Ignoring operation order: document whether discounts are additive, sequential, capped, or subject to another specified sequence.
- Rounding inconsistently: apply the stated rounding point and precision to both the expected result and the system comparison.
Check Your Understanding
For each problem, determine the expected result or test conclusion using the rules provided.
- A hypothetical rating rule applies a factor of 0.90 when annual receipts are less than $80,000 and 1.05 when receipts are at least $80,000. The base premium and all other factors multiply to $700. What premiums should be expected at receipts of $79,999 and $80,000? (Answer: $630.00 and $735.00.)
- A hypothetical policy has a $900 base premium. Eligible discounts are additive and capped at 9%; a 6% discount and a 4% discount both qualify. The minimum premium is $800, applied after discounts. What is the expected premium? (Answer: $819.00.)
- Use the same $900 base premium, 6% discount, 4% discount, 9% cap, and $800 minimum as in question 2. The 4% discount requires a current document, but the document is expired. What is the expected premium? (Answer: $846.00.)
- A regression reconciliation has expected premiums of $420, $560, and $630, and system premiums of $420, $550, and $640. Calculate both totals and the case-level differences. Does the batch pass if each case must agree to the cent? (Answer: Both totals are $1,610; differences are $0, −$10, and +$10; the batch fails.)
- A test has an expected premium of $2,400. The acceptance rule requires both an absolute difference no greater than $0.02 and a relative difference no greater than 0.1%. The system returns $2,402.00. Does it pass? (Answer: No; the $2.00 absolute difference exceeds $0.02, even though the relative difference is approximately 0.0833%.)