Template · Bug Find / Fix Estimation
The model that says when you will run out of bugs.Tester-day and developer-day rates, geometric cycle decay, daily curves you can plot against actuals.
A quantitative find / fix estimation model that projects the bug-discovery and bug-closure curves for system test. Inputs: daily find and fix rates, headcount, expected defects. Outputs: cycle-level and day-level cumulative-found / cumulative-fixed curves plus the sizing check ("do we have enough developers to keep up with testing?").
- Test cycles modeled
- 6 + acceptance
- Cycle decay
- 50% geometric
- Output curves
- Daily + cycle
Test-cycle planning without a find / fix model is wishful thinking. A quantitative model projects when bugs will arrive, when they will be closed, and (critically) whether there are enough developers on the other side to keep the curve from flattening. Actuals are then plotted against projections; divergence is a planning signal, not a surprise.
Key takeaways
Four things to remember.
01
Two daily rates, two headcount inputs
Find side: bugs-per-tester-day × testers. Fix side: bugs-per-developer-day × developers, capped at what the dev team can actually process. The two rates together set the whole shape of the cycle.
02
Cycles decay geometrically
The 50% / 25% / 12.5% / 6.25% / 3.1% / remainder pattern fits most programs well: most bugs surface in cycle 1, half the rest in cycle 2, and so on. Programs that do not match this shape usually have a scope problem (regression re-opening bugs) or a test-design problem (same tests running cycle after cycle).
03
Developer-capacity is the silent killer
If "max bugs per day fixed" is less than "bugs per day found," the bug backlog grows every day. The model makes that visible immediately. Dev-team-too-small is the single most common cause of system-test cycle slip; the model catches it before the program starts.
04
Plot actuals against projections daily
The day-level output (two curves: total-found, total-fixed) is what lets you catch divergence at week 1 of test rather than week 4. See the Metrics Part 3 whitepaper for the interpretation rules.
Why this exists
What this template is for.
The downloaded .xls runs the model with two illustrative parameter sets: a larger program (8 testers, 12 developers, 300 bugs) and a smaller one (4 testers, 4 developers, 120 bugs, with bug inflow derived from developer-day estimate). Use either as a starting point and overwrite the parameters for your engagement.
The column reference below documents what each input and output means, including the failure modes that show up if you get a parameter wrong.
The columns
What each field means.
The population the model is sizing. Can be a direct estimate or derived from (bugs-per-developer-day × developer-days-until-test-entry). Typical range: 200–2,000 at system-test entry for enterprise programs; 10–50 for small programs.
Empirical rate from prior programs. Typical values: 1.25 / day for complex enterprise (UI + backend + integration); 2.0–3.0 / day for narrower scope; higher (5+) signals over-counting, lower (<0.5) signals test-design problem.
Effective headcount (full-time equivalents net of planning, reporting, reviews). For ramping teams use a profile per week, not a single number.
Product of the two above. The maximum daily find rate the team can sustain.
Total bugs ÷ bugs-per-day. Sets the minimum test-cycle duration before acceptance. Use this to sanity-check schedule.
How many test cycles the calendar supports, typically 1 per week (traditional enterprise), 2–3 per week (faster programs), continuous (CI-integrated). The cycle cadence sets the cycle decay interval.
How many bugs a developer can triage-diagnose-fix-retest per day. Typical: 1.0–2.0 for integration-layer bugs; 0.5 for tricky concurrency / race-condition bugs; higher for trivial UI/config bugs. Underestimating this masks capacity problems.
Developers whose time is committed to bug fixing during the test window. Often lower than the development-team headcount because developers are simultaneously working on other scope. Use committed, not total.
Product of fix rate × developers. This is the ceiling on backlog burn-down; if daily find exceeds daily fix, the backlog grows.
Average days from bug filed to bug closed. Calibrated against the 2,929-row closure histogram in the download. Typical: 7–14 days for well-run enterprise; over 21 days is a process problem (see Metrics Part 2).
% of bugs found in each cycle. Canonical: 50 / 25 / 12.5 / 6.25 / 3.1 / 3.0 / 0 (acceptance). Replace if prior programs have a different shape; keep the sum at 100%.
Running total of bugs expected to be found by end of each cycle. Plotted against actuals to catch divergence.
Running total of bugs expected to be closed by end of each cycle, accounting for the fix rate × developer capacity × closure period. Divergence between found and fixed is the capacity-shortfall signal.
Day-by-day projection across the test window. This is the artifact you plot actuals against in every status review.
Cycle decay · canonical shape
50, 25, 12.5, 6.25, 3.1, 3. Then acceptance.
Risk-ordered testing mines the highest-yield tests first. Each successive cycle finds a smaller fraction of the remaining defect population. Plot your program’s actuals against this shape, divergence is the planning signal.
Percent of total bugs found per cycle
Canonical geometric decay
Programs that don't match this shape usually have a scope or test-design problem.
A flat shape across cycles indicates lower-yield tests running too early (fix risk-ordering). A plateau in cycles 3–4 indicates the same tests running repeatedly (add exploratory sessions; rotate scenario ownership).
Live preview
What it looks like populated.
Canonical cycle-decay curve (%). Plot your program's actuals against this shape; divergence is the planning signal.
| Cycle | % found in cycle | Cumulative % found |
|---|---|---|
| 1 | 50.0% | 50.0% |
| 2 | 25.0% | 75.0% |
| 3 | 12.5% | 87.5% |
| 4 | 6.25% | 93.75% |
| 5 | 3.13% | 96.88% |
| 6 | 3.00% | 99.88% |
| Acceptance | 0.12% | 100.00% |
Daily curves · find vs. fix
The capacity-coupling view.
Cumulative bugs found (projected) vs. cumulative bugs fixed (projected). The gap between them is the open-bug backlog. If find > fix day over day, the backlog grows and the cycle slips. This model surfaces that before the program starts.
30-day test window · illustrative
Cumulative bugs, found vs. fixed
Find rate = 14/day tapering; fix capacity capped at 10/day.
Below-projection at week 1 = test-readiness failure (environments, data, entry criteria). Above-projection at week 1 and flattening at week 2 = scope creep or environment instability. See Metrics Part 3 for the interpretation rule set.
How to use it
6 steps, in order.
- 1
Estimate total expected bugs first. Use a developer-day × bugs-per-developer-day calculation if you have historical rates; otherwise use a risk-weighted sampling estimate (high-risk items expected to find N bugs each, medium M, low L, sum).
- 2
Populate the find side: bugs-per-tester-day and testers-assigned. Use your team's measured rate from the last two programs; the industry range (1–3 bugs/tester-day) is a sanity check, not a substitute for measurement.
- 3
Populate the fix side: bugs-per-developer-day and developers-committed. The "committed" number is critical, not the development-team total. If bugs-per-day-found > max-bugs-per-day-fixed, either increase the fix capacity or increase the expected cycle length (and warn the program about it).
- 4
Verify the cycle decay against your historical data. If prior programs show a flatter curve (40 / 25 / 15 / 10 / 5 / 5), substitute. The model supports any decay so long as it sums to 100%.
- 5
Generate the daily curves. These are the projection artifact, publish them in the test plan and include them in every status update so divergence is visible.
- 6
In each status cycle, plot actuals against the projection. The Metrics Part 3 whitepaper covers interpretation: below-projection at week 1 usually means test-readiness failure; above-projection at week 1 and flattening at week 2 usually means scope creep or environment instability.
Rates to calibrate · four numbers
Two daily rates. Two headcount inputs.
Empirical, from your last two programs. Industry ranges are sanity checks only, never substitutes for measurement.
Methodology
The thinking behind it.
The geometric cycle-decay pattern (50 / 25 / 12.5 / …) is empirical, it fits most programs because the highest-yield tests run first (risk-ordered), and each subsequent cycle mines a smaller fraction of the remaining defect population. A flat shape across cycles indicates insufficient risk-ordering (lower-yield tests are running too early); a front-loaded shape (70 / 20 / …) indicates the test basis is unusually complete from day one.
Developer-capacity coupling is the one equation that determines whether the program runs smoothly or painfully. When find rate > fix rate, the open-bug backlog grows; the "acceptance" cycle in the model captures the residual defects that were found but not fixed. Programs that consistently find > fix during system test either (a) defer most bugs as minor, (b) extend the timeline, or (c) trigger an emergency developer shift from feature work to fix work. The model exposes this to program management ahead of time.
For continuously-delivered programs, the model adapts but its tempo changes: "cycles" become weeks or days; "acceptance" becomes production canary; the decay pattern holds across the lifetime of a feature-flag rollout. The same curves (projected vs. actual) still apply.
Closure-period calibration, the 2,929-row histogram included with the download is from a representative mid-2000s enterprise program. For 2026 calibration: in DORA-era organizations, mean closure periods are lower (3–7 days) because continuous-delivery teams resolve bugs faster and have fewer handoffs; but variance is higher because a small tail of hard-to-reproduce bugs drags the average up. Plot YOUR organization's distribution, not this one, when calibrating.
The companion deck
Drop your details to unlock the full slide deck in-page. We will email you a copy too.
Take it with you
Download the piece you just read.
The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.
In the library
Pair this with.
Process · Test Estimation
Estimate testing the way projects actually work.
Test estimates fail either because they skip the work breakdown or because they skip stakeholder buy-in. This process does both, in sequence, so the resulting schedule and budget survive contact with management.
Read →Template · Test Budget
The test budget structure that survives finance review.
A test budget template that covers the five enterprise categories (staff, travel, tools, test environments, external labs) month by month, pairs with an explicit contingency line, and rolls into a worked ROI model. Adapt the line items, keep the structure.
Read →Process · Bug Reporting
Write bug reports developers act on.
A bug report is a sales document aimed at a developer. This is the ten-step sequence we use on every engagement to write reports that get fixed instead of dismissed.
Read →
Keep reading
Related reading
- Primer
Careers in Software Quality: Roles, Skills, and First Steps
What testers, test automation engineers, quality engineers, and test managers actually do, the skills each role uses, and practical first steps for students and career changers, including the ISTQB Foundation certification.
Read → - Primer
Errors, Defects, and Failures: What a Bug Really Is
Everyone says 'bug', but testers use three precise words: error, defect, and failure. Learn the difference, why it matters, and how severity and priority decide which problems get fixed first.
Read → - Primer
How Software Gets Attacked: Common Vulnerabilities in Plain English
The most common ways attackers break into software, explained without jargon: trusting input, broken access control, weak sign-in, misconfiguration, and outdated components. Each one comes with the defense that stops it.
Read → - Primer
How to Report a Bug So It Actually Gets Fixed
Finding a bug is half the job. Learn how to write a bug report a developer can act on: a clear summary, exact steps to reproduce, expected versus actual results, and the habits professional testers use to make every report count.
Read → - Primer
Security Testing Basics: Finding Weaknesses Before Attackers Do
An introduction to security testing for new testers and developers: thinking in threats, designing abuse cases, testing access control, the role of automated scanners and penetration tests, and the rules that keep security testing legal and ethical.
Read → - Primer
Staying Safe Online: Passwords, Sign-In, Phishing, and Updates
The everyday security habits that stop most attacks: strong unique passwords, multi-factor sign-in, spotting phishing, keeping devices updated, and sharing carefully. Written for students, families, and anyone starting out.
Read →
Practices
Where this leads
- QA & testingSoftware testing
Software quality consulting since 1994: we test the releases that matter, coach your team on the method, and measure how its testing matures.
Book a call →