How do you budget unscripted exploration against scripted testing for a release?

## Why a fixed ratio is the wrong instrument Every team eventually proposes a number — seventy-thirty, or a fixed exploration day per sprint. The number is comforting and it is not a decision. Two areas in the same release can need opposite things: a re-skinned settings page that has not changed behaviour needs a repeatable check that nothing broke, while a newly built decision engine needs a person who is allowed to follow surprises. A single ratio applied across both under-tests one and wastes effort on the other. The useful question per area is: **do we need to discover something, or to confirm something?** Discovery is where the tests worth running cannot be written in advance, because they depend on facts nobody knows yet. Confirmation is where the expected behaviour is already agreed and the job is to show it still holds. ## The allocation heuristics A few signals reliably move an area toward unscripted time: - **Novelty.** The area is new, rebuilt, or integrated with something for the first time. Nobody's imagination of the failure modes is trustworthy yet. - **Thin or contested specification.** If what it should do is being decided as it is built, tests derived from the document will encode the document's gaps. - **Consequence.** Where being wrong is expensive — money, safety, legal standing, irreversible actions — you want someone actively hunting, not only confirming. - **Recent surprises.** An area that produced unexpected defects last release is telling you the team's model of it is wrong. And toward written, repeatable effort: - **An external evidence requirement** — a reviewer outside the team must see what was verified. - **Stability** — behaviour is settled and the risk is regression rather than the unknown. - **Hand-off and comparability** — many people, many configurations, results that must line up. - **Confirmed defects** — once understood, the reproduction is worth fixing in writing. ## A worked allocation A release of a grant-application review queue changes 14 areas. Nine are cosmetic or settled behaviour with an existing written pack: they need re-execution, not attention. Three carry a rebuilt bulk-decision path with a new write ordering — thin specification, irreversible consequences, and this is exactly where a partial-failure rollback was found last time, leaving 11 of 37 applications in disagreeing states across three views. Those three get most of the unscripted budget. The remaining two touch a queue that must hold up at a 1,200-request-per-minute peak; that needs a repeatable procedure so two runs are comparable, plus a person watching during the run, because the interesting failures there are the ones nobody thought to assert. Notice what the allocation is made of: a judgement per area, defensible in a sentence each, and re-made every release rather than fixed as a policy. ## Protecting the budget Unscripted time has a structural weakness in a plan: it has no visible deliverable until it produces one. When the schedule compresses, the written pack survives — it is countable and it is required — and exploration is quietly dropped, which is exactly backwards, because compression usually means the change was bigger or later than planned. Three defences work. First, make it a named, sized block of work in the plan, with an area and a risk attached, so cutting it is a visible decision rather than a silent omission. Second, report it in terms leadership can weigh — areas covered, risks addressed, and specifically what is still unexplored, which is the sentence that gets attention. Third, and most persuasive, run an escaped-defect audit: for each defect that reached production, ask whether any reasonable written check would have caught it. When the answer keeps coming back no, you have direct evidence that the missing capability is discovery, not more procedures. Conversely, if escapes are mostly things a written check would have caught, the honest conclusion is that your regression discipline is the gap and you should say so. ## Who explores, not just how much Budget is also a staffing question. The output of unscripted work scales with product knowledge and with the tester's stock of ideas about how things fail, so the same hour spent by different people returns wildly different value. That argues for putting your most product-literate people on the highest-consequence areas, for pairing a newcomer with them rather than handing a newcomer the risky area alone, and for pulling in people with different models of the system — support staff know what users actually do, developers know where the wiring is fragile. It also argues against treating exploration as a job title's private activity. Where a team is short of testers, deliberately allocated exploration by developers on each other's work buys real information, provided it is given a mission and a hand-back like any other block. ## Answering this in an interview Refuse the ratio, explicitly and politely, then give the per-area rule and two or three signals on each side. Finish with how you would know the split was wrong — the escaped-defect audit — because that is what separates a principal answer from a confident opinion.