Derived Boundaries in a Premium Rating Engine

The 40 cases tested the input domain of the form, but the defect lives in a derived value. Age is a function of date of birth and effective date, and maturity age = age + term, so two classes were never exercised:

1. The predicate boundary age + term <= 75, which is crossed by pairs of individually valid inputs (age 46 with term 30 gives 76).
2. The truncation boundary of 'completed years', which falls mid-year for every applicant because the real input variable is a date, not an integer.

Testing 18 and 65 as integers exercises a field the applicant never types. The additional cases are:

• DOB giving exactly 17y 364d and 18y 0d; exactly 65y 0d and 65y 364d (the latter must be rejected if the rule is 'completed years <= 65').
• Maturity exactly 75y 0d (valid) and 75y 1d (invalid), e.g. term 30 with age 45 and 45y 1d.
• Effective date equal to the applicant's birthday, and the day after.
• 29 February DOB.
• The interaction pair term = 30, age = 46, the highest-risk combination of two valid inputs.

This is boundary-value analysis on a cross-field computed variable, not on a single field; the lesson is to derive boundaries from every predicate in the specification, including calculated ones.

Pairwise covers 2-way factor interactions. With age at 48 values, a pairwise set cannot be smaller than 48 and a tool will typically emit 50-60 cases, against a full cross product of 48 x 30 x 4 x 2 x 6 = 69,120. Two problems: pairwise assumes risk is spread evenly across interactions, and it does not model rules such as the maturity predicate or discount stacking, which are not factors.

A defensible design under the constraint:

1. Collapse continuous inputs into equivalence classes first: age becomes under-18, 18-25, 26-45, 46-64, exactly 65, over 65, plus the derived maturity classes; term becomes 1, 2-5, 6-10, 11-29, 30. That reduces age to about 7 and term to 5.
2. Add explicit boundary-value cases at every class edge and at the maturity predicate (both sides, on and off).
3. Build a decision table for the loyalty/multi-policy rules with don't-care minimisation, one case per feasible rule, and use it to expose the two contradictory combinations.
4. Then apply pairwise over the reduced factors (7 x 5 x 4 x 2 x 6), about 40 cases, to catch residual interactions.
5. Rank by risk so the top 25% runs first if time is consumed.

Stopping rule: every rule in the specification has at least one case, and every boundary has a case on each side.

Contradictory rule outcomes are a specification defect, not a test-case problem, and finding them is a legitimate output of decision-table construction. The team should not silently pick one result.

Procedure:

• Enumerate the four conditions (loyalty tenure, multi-policy, payment method, region) as a complete decision table. With four binary conditions there are 16 combinations before merging; merge using don't-care entries where an outcome does not depend on a condition.
• Mark the two rules whose actions conflict for the same condition set. In the table this appears as two rules with identical condition entries but different actions - impossible to satisfy simultaneously.
• Escalate to the business analyst with a concrete question: for a customer who holds both a 6-year loyalty record and a second policy, is the discount 5%, 7%, a capped 10%, or the maximum of the two? Ask also what the cap is and whether the discounts stack multiplicatively or additively.
• Until answered, record both outcomes as a blocking ambiguity, write one case per rule as currently specified, and expect one to fail. Do not mark either as 'expected' from tester judgement.

After the rule is clarified, one case per remaining feasible rule plus one case per boundary of the cap gives complete decision-table coverage with roughly 8-10 cases instead of 16, and the table becomes a durable regression asset and a reviewable artefact for the next rule change.