What is a regression budget?

A regression budget is a cap on how many bugs that were previously fixed can come back per release. You measure regressions automatically and enforce the budget in your release process. The budget forces the team to invest in test coverage for the areas that keep breaking.

How do I measure regressions in a game?

Tag every bug in your tracker with the release it was fixed in. When a new bug reopens or closely matches an old one, tag it as a regression. Count regressions per release and compare against the budget. Many bug trackers support a 'Regressed' status or tag for this purpose.

What should a reasonable regression budget look like?

Start with a cap of 5% of the previous release's fixed bugs. If you fixed 20 bugs in v1.5, the v1.6 regression budget is 1. Adjust based on your team's capacity and the nature of the game. The specific number matters less than the discipline of measuring and enforcing it.

How to Set Up a Regression Budget for Your Game

Quick answer: Tag regressions explicitly in your bug tracker, count them per release, and enforce a cap (start with 5% of the previous release’s fixed bugs). A release that exceeds the budget gets held until regressions are fixed. The discipline is more important than the specific number.

Your team fixes 20 bugs in a release, ships it, and three weeks later 8 of the fixes have come back. The team starts to wonder if they are moving forward at all. A regression budget is a management technique that caps how many old bugs can return per release — and makes the cost of poor test coverage visible on the release calendar.

Why Regressions Feel Worse Than New Bugs

A new bug is expected. Software has bugs. A regression is a broken promise. You told players “this is fixed” and then broke it again. Regressions damage trust faster than new bugs do, and they are almost always preventable if you add a test when you fix the bug.

The unfortunate reality is that “I will add a test next time” is how regressions ship. A budget turns “next time” into a hard constraint.

What a Regression Budget Looks Like

The budget is a simple rule:

Each release may contain no more than N regressions of bugs fixed in previous releases. If the number exceeds N, the release is held until regressions are fixed.

N is small. Start with 5% of the previous release’s total bugs fixed, rounded up. If you fixed 20 bugs in v1.5, the v1.6 budget is 1. If you fixed 100 bugs in v1.5, the budget is 5. The ratio matters more than the absolute number — small teams and small releases should not face the same quota as a 30-person team.

Step 1: Tag Regressions in Your Tracker

You cannot enforce what you do not measure. Add a “Regression” flag or tag to every bug in your tracker. When a new bug comes in and matches a previously-fixed bug:

Mark the new bug as a regression.
Link it to the original bug.
Record which release first fixed the bug and which release broke it.

Be strict about what counts as a regression. If the bug is subtly different (same symptom, different root cause), it is a new bug, not a regression. If the bug is an exact repeat of something you fixed, it is a regression.

Step 2: Automate the Count

Every week (or at release time), run a report: how many bugs tagged “Regression” were introduced in the current release window?

-- SQL against a simple bug tracker schema
SELECT COUNT(*)
FROM bugs
WHERE tags @> '["regression"]'::jsonb
  AND first_seen_release = 'v1.6'
  AND regressed_from_release IS NOT NULL;

Put the count on a dashboard the whole team sees. Weekly trend matters more than snapshot — a climbing regression count means the next release will bust the budget.

Step 3: Enforce at Release

In your release checklist, add a line:

[ ] Regression count <= budget ({current_count} / {budget})
    If over, one of:
      - Fix the extra regressions
      - Defer the regressed bugs to a hotfix and hold the release
      - Explicit override from team lead with written justification

Make the check visible and automatic. If the budget is 1 and the release has 2 regressions, the CI release step fails. The team has to consciously decide to override.

Step 4: Write Tests for Every Regression

Every time a regression is found, the fix commit must include a test that would have caught it. This is the most important rule. Without it, the same bug will come back a third time.

The test does not have to be a unit test. It can be:

An automated gameplay smoke test.
A screenshot baseline.
An assertion in startup code that validates a specific invariant.
A manual QA checklist item that is run every release.

Whatever it is, it must exist before the fix is merged. “I will add a test next sprint” is not acceptable because the whole reason you are writing the test is to catch regressions in the next sprint.

Handling Overrides

Sometimes a regression budget needs to be waived. A critical fix reintroduces a small visual glitch that is not worth delaying the release. Fine — but the waiver goes in writing:

Waiver: v1.6.2 regression budget exceeded (budget 1, found 2)
Waived by: James (team lead)
Justification: Security hotfix must ship today. Regressed bug is
               cosmetic and scheduled for v1.6.3 next week.
Date: 2026-04-10

Keep the waivers in a file checked into the repo. If they pile up, the team is either too loose with the budget or needs to set a more realistic number.

What a Good Budget Looks Like Over Time

A healthy team sees:

Regression count per release: stable or declining over months.
Number of budget waivers per quarter: low (one or two).
New tests added per regression: ~1.0 (every regression gets a test).
Total test count: growing steadily.

An unhealthy team sees:

Regression count climbing release over release.
Frequent waivers, often without written justification.
Regressions of regressions (same bug fixed three times).
Test count stagnant.

If you see the unhealthy pattern, the budget is doing its job — it is telling you the team is not investing in tests. That is the real problem to address.

“A regression budget does not prevent regressions. It makes the cost of poor test coverage visible. Once the team sees the cost, they fix the coverage.”

Related Resources

For the broader regression testing strategy, see regression testing strategies for indie games. For writing tests specifically for bug fixes, see how to write regression tests for game bugs. For catching regressions early, see how to catch regression bugs early in development.

The first release with a regression budget will feel painful. The tenth will feel normal. By the twentieth, regressions are rare and the budget is easy to meet. Stick with it.