How do you buffer a test estimate for fix-and-re-test cycles and days lost to blocked builds?

## The first pass is not the job Sizing the first pass - execute every planned check once - is the easy half. What consumes a cycle is what happens after the first failure, and estimates that stop at the first pass are the most common way a test schedule goes wrong. Two distinct mechanisms add the rest, and they need separate treatment because they respond to different levers. ## Driver one: fix-and-re-test churn A defect costs far more than the minutes spent reporting it. Each one carries investigation and isolation before it can be filed, a wait on fix turnaround that consumes calendar rather than effort, confirmation that the fix works, and re-execution of whatever coverage the fix invalidated. That last part is where estimates break. Consider a grant-application review queue whose 340-case regression pack was mostly green when a defect surfaced in the ordering assumption: applications were being ordered by score where the queue's rule was submission timestamp within a funding round. The fix changed the ordering everywhere, which meant 61 already-passing cases across pagination, reviewer assignment and the summary counts were no longer trustworthy and had to run again. Three fix rounds later, the pack had been partly re-run three times. None of that appeared in a first-pass estimate. The sizing inputs are measurable: **defects per unit of scope** from comparable past cycles, **median fix turnaround** (that queue's previous cycle measured 1.7 days), and **re-test cost per defect** as a fraction of first-pass effort - the confirmation plus the invalidated slice. Multiply, do not guess. And treat the tail honestly: the distribution is skewed, because a single defect in a shared assumption can invalidate a large fraction of the pack while twenty cosmetic ones invalidate nothing. ## Driver two: availability The second driver is that planned days are not usable days. Builds fail to deploy, an environment goes down, a dependency's stub is stale, the test data has not been refreshed. Track the fraction of planned days on which the team could actually test - if the last cycle gave 3.8 usable days out of every 5, that 0.76 is a measured property of the environment, not pessimism. Note the arithmetic difference between the two drivers. Re-test churn *adds work*; availability *shrinks the working week*. Availability therefore divides rather than adds, and that distinction matters when the number is challenged: ``` first_pass_days = 36.05 defects_expected = 32.4 // from measured arrival rate retest_days = 32.4 * 0.35 // confirm + invalidated slice per defect usable_fraction = 3.8 / 5 // measured last cycle total = (36.05 + 11.35) / 0.76 // = 62.4 elapsed tester-days ``` ## Named buffer, not hidden padding The instinct is to pad each task by a comfortable margin. Resist it, for three reasons. Padding compounds invisibly, so nobody - including you - can say how much of the estimate is contingency. It is unfalsifiable, so it cannot be defended when challenged; a manager who cuts 20% has no idea what they removed. And it destroys the feedback loop, because the actuals come back against inflated tasks and your rates never improve. Instead make the buffer a line item with a **stated trigger**: "re-test allowance: 11.4 days, assuming defect arrival matches the last two cycles" and "availability allowance: assumes at least 3.8 usable days per five-day week". Now the buffer is a claim about the world. If the environment turns out to be up every day, the allowance is released and you say so. If the build is blocked for a week, the assumption has failed publicly and the estimate changes with a reason attached rather than a quiet overrun. ## Quote a range, carry the assumptions The output shape follows from all of this: a range, with the assumptions that would move it named beside it. The optimistic end is the world where defect arrival is low and the environment holds; the pessimistic end is the world where a shared assumption breaks late and re-invalidates a large slice. Listing the assumptions is what makes the range actionable - each one is something somebody can go and change. Better environment availability, faster fix turnaround, or earlier delivery of the riskiest area all narrow it, and that is a far more productive conversation than arguing about the number itself. ## Re-estimating in flight A buffer is not a one-time calculation. Once the cycle starts, real defect arrival and real availability replace the assumed ones, and the estimate should be re-issued when they diverge materially. Two things are worth stating up front so this is expected rather than alarming: which measurements you will watch, and what magnitude of divergence triggers a re-issue. An estimate that is never revised in the face of contradicting evidence has stopped being an estimate and become a promise.