Quote Rules, Escaped Defects, and the Third Tester
Northwind Insurance runs two-week Scrum sprints with six developers, two testers, one product owner, and a business analyst. The quote-calculation feature has 34 eligibility rules that interact: customer age, region, vehicle group, claims history, and payment frequency. Acceptance criteria are one-line statements such as 'premium is calculated correctly'. In the last three sprints, 14% of defects reached production, mostly missing rule combinations and rounding errors. The team writes automated unit tests but no business-facing examples. The product owner wants to add a third tester; the test lead believes a collaborative technique would prevent more defects than extra execution capacity. A regulatory audit in eight weeks requires traceability from rules to tests. The next sprint contains three quote stories, including a new 'young driver with prior claim' rule.
1. Recommend an agile testing technique to reduce the escaped rule defects, and justify it against hiring a third tester. Describe the workshop steps and the artefacts that would satisfy the audit traceability requirement.
Read the worked answer
The dominant defect pattern is missing rule combinations and rounding, not insufficient execution speed. A third tester would mostly increase detection after development, while the requirements gap would remain. The stronger intervention is example mapping inside an ATDD/three-amigos flow.
Workshop steps
- Hold a 45-minute example-mapping session before refinement: product owner, business analyst, developer, tester.
- Write the story as a yellow card, then list each business rule on a separate card.
- For every rule, write at least one concrete example with real values; put unanswered questions on red cards.
- Use the examples to derive acceptance criteria; mark combinations where the rule is silent as open questions, not assumptions.
- Convert the agreed examples into automated unit/API tests and link each test to a rule ID.
Artefacts for audit: rule catalogue, example set, open-question log, acceptance criteria, and a traceability matrix mapping rule IDs to automated and manual tests. This prevents defects earlier and produces the evidence the auditor needs. Do not start by buying a BDD tool; the collaboration and examples come first.
2. For the new 'young driver' rule the business states: age under 25 with at least one prior claim gets multiplier 1.8; age 25-64 with no claims gets 1.0; age 65 or over gets 1.3; coastal region adds 0.2 to the multiplier; monthly payment adds a 3% surcharge. Identify the conditions, design decision-table test cases, include boundary values, and explain how you would reduce the table without losing meaningful coverage.
Read the worked answer
Conditions: age band (<25, 25-64, >=65), prior claim (yes/no), coastal region (yes/no), monthly payment (yes/no). A full table would have 3 x 2 x 2 x 2 = 24 columns, but the rules do not define every combination, for example a 25-64 driver with a prior claim. Those gaps must become questions, not invented behaviour.
Representative test cases
- Age 24, prior claim yes, coastal yes, monthly yes: base 1.8 + 0.2 = 2.0, then 3% surcharge. Expected premium = base x 2.0 x 1.03.
- Age 24, prior claim no: rule is undefined; raise a question and do not automate a guess.
- Age 25, no claim, inland, annual: multiplier 1.0.
- Age 64, no claim, coastal, annual: 1.0 + 0.2 = 1.2.
- Age 65, no claim, inland, annual: multiplier 1.3.
- Age 65, prior claim yes: undefined; question.
Boundary values: ages 24/25 and 64/65; multiplier arithmetic at the coastal surcharge and the 3% rounding point. Reduction: first remove impossible or undefined combinations by clarifying them; then apply pairwise/orthogonal selection to low-risk combinations, but keep all one-factor boundaries and all high-risk claim combinations. The reasoning is to preserve coverage of rule boundaries and interactions while cutting redundant low-risk permutations.
3. How should exploratory testing be integrated so that it complements, rather than duplicates, the decision-table tests and still helps in the regulatory audit?
Read the worked answer
Use exploratory testing for risks that a decision table handles poorly: rule interactions across the 34 rules, data-quality effects, end-to-end quote journeys, rounding at realistic premium values, and usability of error messages. Do not re-run the table combinations.
Write session-based charters such as 'Explore young-driver coastal monthly quotes around claim-count boundaries' or 'Explore how missing vehicle-group data affects quote accuracy'. Time-box sessions to about 90 minutes, record coverage notes, environment, data used, and any defects. Debrief with the team so findings update the rule catalogue and automation backlog.
For audit purposes, keep session sheets showing charter, time, areas covered, observations, and reviewer. Link charters to the risk register and to rule IDs where relevant. This gives evidence of professional judgement rather than only scripted execution, while the decision table remains the traceable backbone.