Fourteen Days, Six Modules

Risk is likelihood times impact, and defect density gives only the likelihood half. I would use a simple, defensible scoring of three factors: historical density, business impact if broken (money, data integrity, regulatory), and complexity/novelty of the change.

Module	Density	Impact	Proposed days
Points accrual	4.1	Money-critical; every member balance	15
Redemption catalogue / voucher codes	2.8	Revenue-facing; combinatorial input logic	12
CSV bulk import	1.9	One-shot bulk write; errors corrupt many records at once	8
Tier-upgrade rules	1.2	Moderate density but tangled effective-date logic; members see wrong tier	7
Admin reporting	0.6	Read-only, low blast radius, but totals must reconcile	5
Email templates	0.3	Functionally trivial, but highly visible externally	3
Total			50

Justifications and adjustments:

• Do not rank purely by density. Emails score lowest on density yet are customer-visible, so they get a small, fixed allocation (rendering across the main clients, one negative case each) rather than none.
• Import gets more than its density implies because its failure mode is bulk and irreversible; a single unhandled quoting case corrupts thousands of rows.
• Reporting gets exploratory time rather than scripted case volume: the real risk is that totals disagree with source data, which a checklist catches better than a case count.
• The 12-day regression and 8-day retest figures are estimates. Re-plan at day 5 using actual defect arrival data; if accrual defects are still arriving, move days from reporting and emails.
• Hold roughly 10% unallocated for the inevitable blocker.

The stakeholders' 'equally important' is not a testable statement; force a ranking by asking what they would cut first if only three modules could ship.

Equivalence partitions (each partition needs at least one test):

• Length: 0-7 (invalid, too short), 8-12 (valid), 13+ (invalid, too long).
• First character: letter (valid), digit (invalid), symbol/space (invalid).
• Remaining characters: alphanumeric only (valid), contains space, hyphen, underscore, accented or CJK character, emoji (invalid).
• Case: all lower, all upper, mixed (all should behave identically per the case-insensitive rule, so one representative each is enough to prove the rule, not three times the whole suite).
• Quantity applied: one code per order (valid), second code attempted (invalid, should be rejected with a clear message).
• Lifecycle state: not yet valid, valid, expired, cancelled, already fully redeemed.
• Whitespace handling: leading/trailing spaces trimmed or rejected consistently.

Boundary values (3-value BVA around the length rule): 7, 8, 9 and 11, 12, 13. Also probe 0 (empty) and a very long input (e.g., 200 characters) for truncation or buffer handling. Two-value BVA (7/8 and 12/13) is the minimum; the third value on each side catches off-by-one errors that land one inside the boundary.

Why not cross-product: length partitions (3) x first-character (3) x charset (5) x case (3) x quantity (2) x lifecycle (5) x whitespace (2) is 2,700 combinations for one field. Most are equivalent in outcome. Use pairwise or a hand-picked set of roughly 20-25 cases that covers every partition at least once and every known risky pair (empty plus expired; 13 characters plus uppercase; second code plus already redeemed). Then add targeted error-message checks, because a correct rejection with a misleading message is still a usability defect.

Start by quantifying what was asked. 4 x 3 x 5 = 60 combinations before any voucher, data or lifecycle variation is added. Multiply by even 10 business scenarios and it is 600 executions per regression cycle, on a module that has 12 allocated days. The request, taken literally, cannot be satisfied, so agreeing to it verbally while doing something else is the worst outcome.

Counter-proposal, with reasons:

1. Prune by data, not by feeling. Pull analytics on browser share and payment-method usage. If one browser is under 1% of sessions and unsupported by the vendor, drop it and document the decision. Supported-version policy should be a business decision, not a testers' guess.
2. Use pairwise (all-pairs) coverage for the 60 combinations, which typically yields 15-20 tests while still exercising every pair of values. Most defects are triggered by one parameter or an interaction of two, so pairwise catches the common classes at roughly a third of the cost.
3. Add targeted 3-way combinations only where history says risk lives - for example, a specific locale with a specific payment method and a specific role, if that triple has produced incidents before.
4. Layer in risk-based scenarios for money-critical paths: one full end-to-end redemption per payment method, because a failure there is a revenue failure regardless of browser.
5. Add exploratory sessions to catch what combinatorial coverage cannot: sequence effects, session expiry mid-flow, back-button behaviour.

Write the trade-off into the test plan: what is covered, what is deliberately not, and who accepted that risk. That converts an argument into a decision record.