Calculating Bug Burn-Down for Game Code Freeze

In game development, knowing precisely when a build is stable enough for code freeze is critical to meeting milestone deadlines and console certification requirements. Quality Assurance (QA) leads calculate bug burn-down metrics to measure the trajectory of defect discovery against defect resolution over time. By tracking incoming defect rates, resolution velocity, reopen rates, and severity distributions, QA leads can mathematically forecast when a game will reach acceptable stability, removing guesswork from the decision to freeze code.

Key Data Points for Burn-Down Metrics

To calculate burn-down velocity, QA leads monitor four primary data points daily or per sprint:

  • Defect Arrival Rate (\(A\)): The number of new, unique bugs logged per day.
  • Defect Resolution Rate (\(R\)): The number of bugs verified and closed by QA per day.
  • Reopen Rate (\(O\)): The percentage of resolved bugs that fail verification and are sent back to engineering.
  • Defect Backlog (\(B\)): The total count of active, unresolved bugs.

Calculating the Net Burn-Down Rate

The foundational calculation for stability is the Net Daily Burn-Down Rate (\(N\)):

\[N = R - A\]

  • If \(N \le 0\), the bug backlog is growing or stagnant; the game is destabilizing.
  • If \(N > 0\), the team is resolving more defects than are being introduced; the build is converging toward stability.

To estimate the days required to reach target stability (\(T\)), QA leads divide the open backlog (\(B\)) by the average net burn-down velocity over a trailing 7- to 14-day window (\(\bar{N}\)):

\[T = \frac{B}{\bar{N}}\]

An adjustment for the Reopen Rate (\(O\)) is often applied to ensure realism:

\[\text{Effective Resolution Rate} = R \times (1 - O)\]

Factoring in Defect Severity

Raw bug counts can be misleading; ten minor UI typos do not equal one game-breaking crash. QA leads calculate a Weighted Defect Score (WDS) to track true build health:

\[\text{WDS} = (B_{\text{Blocker}} \times 10) + (B_{\text{Critical}} \times 5) + (B_{\text{Major}} \times 3) + (B_{\text{Minor}} \times 1)\]

Code freeze stability is typically measured by the burn-down of weighted severity rather than absolute numbers. A downward-trending WDS indicates that the game is mechanically stabilizing, even if the total minor bug count temporarily rises due to focused visual testing.

Code Freeze Stability Criteria

A QA lead declares code freeze readiness when the burn-down trends meet specific, predefined thresholds:

  1. Zero Blocker and Critical Bugs: The count of game-stopping crashes, progression blockers, and fatal compliance issues must reach zero and stay at zero for at least 48 to 72 hours.
  2. Stable Negative Trajectory: The Net Burn-Down Rate (\(N\)) must remain consistently positive for two consecutive sprint cycles or milestone reviews.
  3. Low Reopen Rate: The reopen rate must fall below a target threshold (typically under 5% to 8%), proving that bug fixes are durable and not introducing regressions.
  4. Arrival Rate Flattening: Despite exhaustive test passes across all supported platforms, the Defect Arrival Rate (\(A\)) must show an asymptotic decline toward zero, indicating test coverage saturation.

Once these conditions are satisfied mathematically, the QA lead greenlights the code freeze, allowing the team to transition from feature-level bug fixing to release candidate validation.