Calculator lookup tables
Calculator Lookup Table Test Matrix: 16 Boundary Cases
A reusable lookup-table contract and sixteen executed cases for calculator tiers, rates, dates, units, gaps, overlaps and missing rows.
Direct answer
Give every calculator lookup table an explicit key type, ordered non-overlapping ranges, one inclusion convention, one value scale, effective dates, a version and a defined unsupported state. Validate the table before release, then test immediately below, at and above every boundary. If a valid key matches zero or multiple rows, stop the calculation and explain the unsupported state instead of inventing a fallback.
Definition
A calculator lookup table maps a normalized input key or range to a value used by the formula, such as a volume multiplier, regional rate, dated coefficient or product configuration value. The table is part of the calculation model and needs an explicit contract, version and boundary tests.
Key findings
Verified 30 September 2026
- Lower-inclusive and upper-exclusive intervals give each supported key exactly one row when the table is complete and non-overlapping.
- Gaps, overlaps, duplicate ranges, wrong scales and missing rows must fail visibly because each can return a plausible but false result.
- The matched table version belongs with the formula version and completion record so historical results remain reproducible.
- Boundary tests need the value immediately below, at and immediately above every transition—not only representative values from the middle of a tier.
What is a calculator lookup table?
A lookup table selects a value that another formula uses. Common examples include volume discounts, service tiers, regional rates, date-effective coefficients and configuration prices. A table change can therefore change the answer even when the visible formula expression is unchanged.
Version the table beside the formula. Store the table version, normalized key and matched row with the completion record so a displayed result can be reproduced after a rate or policy update.
Which contract fields should be fixed before testing?
Write the selection rules before loading rows. The contract below makes type, interval, scale and fallback decisions reviewable instead of leaving them to row order or implementation defaults.
| Field | Required decision | Fictional example |
|---|---|---|
| Key | Exact field and normalized type | annual_users as an integer |
| Range rule | Inclusive and exclusive edges | lower included; upper excluded |
| Ordering | Deterministic row order | ascending lower bound |
| Value | Output type, scale and unit | decimal multiplier, not percent text |
| Effective period | Start and end behavior | start included; end excluded |
| Fallback | Visible error or documented default | unsupported-state error |
| Version | Immutable identifier | pricing-table-2026-09 |
| Source | Owner and verification date | approved policy checked 30 Sep 2026 |
What did the sixteen lookup-table fixtures test?
Sixteen executed lookup-table fixtures use a fictional table: keys from 0 through 99 select 1.00, 100 through 499 select 0.90, and 500 through 999 select 0.80. Lower bounds are included and upper bounds are excluded. All sixteen returned the documented outcome on 30 September 2026.
LOOKUP-TABLE-BOUNDARY-MATRIX
| ID | Condition | Expected outcome |
|---|---|---|
| L01 | Key equals 0 | Match first row: 1.00 |
| L02 | Key equals -1 | Reject below supported range |
| L03 | Key equals 99 | Match first row: 1.00 |
| L04 | Key equals 100 | Match second row: 0.90 |
| L05 | Key equals 499 | Match second row: 0.90 |
| L06 | Key equals 500 | Match third row: 0.80 |
| L07 | Key equals 999 | Match third row: 0.80 |
| L08 | Key equals 1000 | Reject above supported range |
| L09 | Two rows include 100 | Block overlapping table |
| L10 | Gap between 499 and 501 | Block unmatched supported key |
| L11 | Rows supplied out of order | Fail validation before release |
| L12 | Duplicate range | Block ambiguous match |
| L13 | Numeric key arrives as text | Reject without an explicit normalization rule |
| L14 | Rate stored as 90 instead of 0.90 | Block scale mismatch |
| L15 | Effective-date boundary | Select exactly one dated table version |
| L16 | Matched row missing downstream | Preserve a visible result error; invent no fallback |
How should gaps, overlaps and invalid keys behave?
A gap means a syntactically valid key matches no row. An overlap means it matches more than one. Both are model defects unless the published contract explicitly defines priority. Returning zero, a nearest tier or the first stored row can produce a credible-looking but incorrect result.
OWASP distinguishes syntactic validation from semantic checks such as numeric and date ranges, and recommends server-side validation because client checks can be bypassed. Apply the same principle when the lookup key comes from an integration, imported table or hidden field: normalize deliberately, validate the allowed type and range, and reject ambiguous state before calculation.
What does a tier boundary change in the result?
At 499 annual users, the fictional multiplier is 0.90. With a fictional $10 base price per user, the modeled total is $4,491. At 500 users, the multiplier becomes 0.80 and the modeled total is $4,000. The $491 drop is a property of this sample table, not a recommended pricing design.
The sharp transition shows why both sides of a boundary need product approval and tests. Keep full internal precision, apply the published rounding policy only after the table value enters the formula, and show enough explanation for a visitor to understand which tier was used.
How should lookup-table errors be explained accessibly?
Identify the affected field, describe the accepted range in text and preserve the visitor's other answers. Do not rely on color or a generic invalid-input message. W3C guidance calls for concise, specific error text and a way to locate and correct the error.
Client-side feedback can improve recovery, but the calculation boundary must also reject invalid or manipulated values downstream. Log an operational reason code without exposing table internals or sensitive data to the visitor.
Calculator lookup-table release checklist
Release only after table validation and boundary replay pass together. Re-run the matrix whenever a row, input contract, date rule, unit, scale, formula or downstream mapping changes.
- Every row has one normalized key type, output scale, unit, source and effective period.
- All ranges use the same documented inclusion convention and deterministic ordering.
- Below, at and above every transition are covered by fixtures.
- Gaps, overlaps, duplicate ranges and wrong scales fail before release.
- Zero, negative, blank, text and out-of-range keys have explicit outcomes.
- Formula and table versions are stored with the matched row and completion ID.
- The screen, CRM and email reuse one final result instead of recalculating from different tables.
- Errors identify the affected input in text and preserve recoverable answers.
Method and evidence
Evidence type: Reusable lookup-table contract and sixteen executed deterministic boundary fixtures
- Defined the lookup key, normalized type, interval convention, output scale, effective period, fallback, version and source before evaluating any row.
- Executed sixteen deterministic fixtures against a fictional three-tier table, covering exact boundaries, unsupported keys, overlaps, gaps, ordering, duplicate ranges, type normalization, scale mismatch, effective dates and missing downstream data.
- Treated an unmatched or ambiguous row as an unsupported result rather than silently choosing a nearby, first or default value.
- Rechecked current OWASP input-validation, W3C form-validation and NIST unit-conversion guidance without presenting the fictional table as a pricing recommendation or production benchmark.
Topic score: 4.52 / 5. Business fit 4.8, verified demand 4.2, distinct intent 4.5, original evidence 4.7, citation usefulness 4.4, feasibility 4.5.
Primary sources
- OWASP Input Validation Cheat Sheet ↗Primary security guidance for syntactic and semantic validation, numeric ranges, allowlists and server-side enforcement; checked 30 September 2026.
- W3C WAI: Validating Input ↗Primary accessibility guidance for identifying errors, explaining corrections and supporting recovery; checked 30 September 2026.
- NIST: Unit Conversion ↗Authoritative measurement guidance for explicit factors, units, significant digits and final-stage rounding; updated 6 February 2026 and checked 30 September 2026.
Limitations
- The tiers, rates, version labels, dates and worked prices are fictional editorial fixtures, not pricing advice or observed production data.
- The matrix tests deterministic selection rules; it does not test a named calculator builder, database, locale, browser, CRM, email platform or assistive technology.
- Interpolation, fuzzy matching, multidimensional tables, tax schedules and regulated tariffs need additional domain-specific tests and review.
- OWASP, W3C and NIST guidance supports the validation, accessibility and unit-handling principles; none prescribes this exact fictional table contract.
Verification and corrections
Current validation, accessibility and measurement guidance plus sixteen deterministic lookup-table fixtures verified 30 September 2026.
Recommended retest: Recheck after any key type, row, range edge, unit, scale, effective date, fallback, source or downstream result-delivery change.
Found an error or a changed standard? Use the correction process and include the page URL and primary evidence.
Next step
Apply the evidence to your next release
Use the published method, keep a dated test record and revisit the result after the calculator or its operating rules change.
Open the testing protocol