Crafting Bench Combinatorics Under a Two-Day Window
Your studio ships a survival crafting game. The crafting bench accepts any of four quality tiers (Common, Fine, Superior, Legendary), belongs to one of six station tiers, and holds a stack of materials of size 1, 10, or the maximum of 99. Items are either bound on pickup or unbound. A separate salvage action returns materials and is meant to consume exactly one unit per salvage, but a report claims that salvaging a stack of 99 Superior bound ore removed the whole stack and returned materials for one unit. Test execution for this build closes in two working days and you have one tester. The full cross-product of station tier, quality, stack size and binding state is 144 combinations, before considering recipe yields of 1, 2 or 5 output units and the 30-second vendor buy-back window.
1. You cannot execute 144 combinations in two days with one tester. Which design technique do you use to select the set, and where do you deliberately override it?
Read the worked answer
Use pairwise (all-pairs) as the base technique over station tier (6), quality (4), stack size (3) and binding state (2). That yields roughly 12-16 cases instead of 144, on the correct premise that most defects come from one or two parameters interacting rather than four.
Then override, because pairwise optimizes for coverage breadth and here you already know where the risk is:
- The reported defect class is stack size crossed with salvage. Pairwise may never combine maximum stack with the bound state, so add explicit cases: 99 bound, 99 unbound and 10 bound for each quality tier.
- Station tier is largely an equivalence class: a recipe is either available at that tier or it is not. Collapse the six tiers into minimum tier and one tier above minimum, and spend the saved cases on quality crossed with stack size, which is where the allocator and binding logic actually interact.
- Use a decision table for the salvage outcome, with rules for bound items (do they return nothing, or bound materials?), a full inventory, and an expired buy-back window.
Record the pairwise set and the deliberate overrides as separate test sets, so that if the window shrinks again it is the overrides, encoding what you actually know about the risk, that survive longest.
2. Specify the boundary values you would test for stack size and salvage count, and state the oracle you use for each.
Read the worked answer
Stack size boundaries: 0 (salvage or craft attempted on an empty slot), 1 (a single unit, the classic off-by-one), 2, 98, 99 (maximum), and 100 (an attempt to exceed maximum, which must split or be rejected). Add a partially filled slot, 50 of 99, plus the mixed case where bound and unbound ore have been merged into one slot.
Salvage count boundaries: salvage one unit from a stack of 99; salvage down to 1; salvage the last unit; salvage a whole stack through a hold-to-confirm interaction if one exists; salvage with the inventory one slot from full.
Oracles, stated so a second tester would reach the same verdict:
- The stack decrement equals the units consumed, exactly.
- Returned materials equal unit yield multiplied by consumed units, with the rounding rule for fractional yields written down.
- No zero-valued or negative stack remains in the slot; the slot object is destroyed, not left as a zero entry.
- Slot capacity is released only when the stack reaches zero.
- Bound items never transfer into an unbound stack.
- Buy-back restores the exact item, quality, binding and count within 30 seconds and refuses after.
- All of the above persists across a save and reload.
The mixed bound/unbound slot is the case most likely to be undefined in the design. Get an answer first, then test the answer.
3. If the build window shrinks to one day, what do you cut and what do you refuse to cut, and how do you communicate that?
Read the worked answer
Refuse to cut the cases that reproduce the reported defect class: 99 bound, 99 unbound, stack of 1, last unit consumed, full-inventory salvage. A confirmed data-loss bug on a currency-adjacent loop outranks coverage breadth, and if it is real, the build cannot ship on this branch anyway. Keep save/load persistence of stack state for the same reason.
Cut, in this order:
- Station tiers beyond minimum and one above.
- Quality tiers reduced to Common plus one representative of the higher tiers, unless the suspected bug is tied to Superior.
- Recipe yields of 2 and 5 reduced to one check per recipe family rather than per combination.
- Buy-back expiry reduced to a single after-window negative check.
Then cut within the case count rather than within the oracle: run each surviving case once, and only repeat the salvage matrix.
Communicate in writing and by name: 'station tiers 2-5 not exercised, because the build closes in one day and the salvage path carries the known risk'. An untested area that someone accepted is a managed risk; the same area left unmentioned is a surprise waiting for the player base.