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-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.
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.
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).
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.
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.
Take it with you
Download the piece you just read.
We keep this library free. All we ask is that you tell us who you are, so we know who to follow up with if we release an updated version. One-time form, this browser remembers you after that.
Related in the library
Pair this with.
Need a QA program to back this up in your organization?
If a checklist is not enough and you want help applying it to a live engagement, we can have a call this week.
Related reading
Articles, talks, guides, and case studies tagged for the same audience.
- Whitepaper
Evaluation Before Shipping: How to Test an AI Application Before It Hits Production
The release-gate playbook for AI features. Covers the five evaluation dimensions, how to build a lean golden set, where LLM-as-judge is trustworthy and where it lies, rollout mechanics with named exit criteria, and the regression suite that keeps a shipped AI feature from quietly rotting in production.
Read → - Whitepaper
Choosing the Right Model (and Knowing When to Switch)
A practical framework for matching LLM model tier to task. Covers the four axes (capability, latency, cost, reliability), cascade routing patterns that cut cost 60 to 80 percent without measurable quality loss, switching costs you did not plan for, and the worked economics at 10K, 100K, and 1M decisions per day.
Read → - Whitepaper
Beyond ISTQB: A Multi-Domain Certification Roadmap for Technical L&D
Most engineering L&D programs over-index on a single certification family, usually ISTQB on the QA side, AWS on the infrastructure side, and under-invest across the rest of the technical domains the org actually needs. This paper covers a multi-domain certification roadmap (QA, AI, cloud, data, security, project management, software engineering) with sequencing logic for each level of the engineering ladder, plus the maintenance discipline that keeps the roadmap relevant as the technology shifts underneath it.
Read → - Guide
The ISTQB Advanced Level path, mapped
The Advanced Level landscape keeps changing — CTAL-TA v4.0 shipped May 2025, CTAL-TM is on v3.0, CTAL-TAE is on v2.0. This guide maps all four core modules, prerequisites, exam formats, sunset dates, and which module a given role should take first. Links directly to the authoritative istqb.org syllabi.
Read → - Whitepaper
Bug Triage: A Cross-Functional Framework for Deciding Which Defects to Fix
Bug triage is the cross-functional decision process that converts raw defect reports into prioritized action. Done well, it optimizes limited engineering capacity against risk; done poorly, it becomes a backlog-management ritual that neither fixes the important defects nor drops the unimportant ones. This whitepaper covers the triage process, the participants, the six action outcomes, the four decision factors, and the governance disciplines that keep triage effective in continuous-delivery environments.
Read → - Whitepaper
Building Quality In: What Engineering Organizations Do from Day One
Testing at the end builds confidence, but the most efficient quality assurance is building the system the right way from day one. This whitepaper covers the upstream disciplines — requirements clarity, lifecycle selection, per-unit programmer practices, and continuous integration — that make system-level testing cheap and fast rather than the only thing holding a release together.
Read →
Where this leads
- Service · Quality engineering
Software Quality & Security
Independent test programs, security testing, and quality engineering for systems where defects cost real money.
Learn more → - Solution
Risk Reduction & Clear Decisions
Quality programs and decision frameworks that shift risk discussions from anecdote to evidence.
Learn more → - Solution
Reliable Software at Scale
Quality engineering programs for organizations whose software is now operationally critical.
Learn more →