In this guide 6 sections
Repeat bugs usually have one of three causes. The fix was never covered by a regression check, the test data differs from production, or the patch landed on a branch that the next release did not include. Look at the fix history for one repeat bug to see which applies.
Start with one bug that came back
Pick a single defect that has reappeared at least twice. Find its first ticket, the commit that fixed it and the release that shipped. Then find the release where it returned.
Write the timeline on one page. Dates, branch names, commit hashes and who tested it. The gap in the story is usually obvious within minutes. Include the reporter’s original steps and the environment where it was seen. Add the developer and tester names, since patterns across people can reveal a missing handover.
Do this for three bugs before drawing conclusions. One case is an accident. Three with the same gap is a process fault. Keep the tone neutral and the facts exact. The aim is to find where the process leaks. Nobody will help if it feels like a hunt for blame.
Cause one: the fix had no regression check
A developer fixes the defect, tests it by hand once and moves on. Nothing in the repository proves it stays fixed. Six months later someone refactors the function and the old fault returns. Under release pressure, developers fix the symptom the customer reported. The conditions that triggered it stay untouched, so a nearby variation of the same fault surfaces next month.
Check the fix commit. If it changed code but added no test case, no line in a regression sheet and no automated check, this is your cause.
The cure is small. Every fixed defect earns one permanent check, written from the original steps to reproduce.
- Fix commit has no test file changed
- Ticket has no linked test case
- Same fault reported again after a refactor
- QA sheet last updated before the original fix
Cause two: test data that is not like production
The bug shows up only for the customer with three hundred orders, the account with a blank middle name or the invoice in a second currency. Your staging database holds twenty tidy demo rows, so the tester never sees it. Typical gaps are a staging database restored two years ago and anonymised names with no accents. Payment amounts also never reach the rounding edge cases seen in live use.
Compare record counts, field lengths, null values and odd characters between staging and a masked copy of production. Large gaps explain why a fix passes in test and fails live.
Refresh staging from masked live data on a schedule. Keep a small set of known awkward records that every release test must touch.
Cause three: the patch went to the wrong branch
A hotfix is made on the production branch under pressure. Nobody merges it back to the development branch. The next release is built from development and quietly removes the repair.
Check this by searching the release branch for the hotfix commit hash. If it is missing, you have found it. Git can list commits present in one branch and absent from another. Release engineers can also compare the deployed build number on the production server against the repository tag. That exposes manual file copies nobody committed.
Agree a rule that every hotfix is merged back the same day, and add a release step that compares the two branches before the build.
- Hotfix hash absent from the release branch
- Production runs code that no branch contains
- Config changed on the server but not in the repository
- Two people fixing the same file in separate branches
Tell which cause applies, then fix the habit
Match your three timelines to the patterns above. Missing test files point to cause one. Fixes that pass in staging and fail live point to cause two. Missing commits point to cause three. Many teams have two at once.
Start with the cheapest change. Add a regression check for each bug closed this month, then pick the one habit that stopped the most repeats. Keep the investigation sheet alive afterwards, so that every reopened ticket gets one row and a named cause, and the pattern becomes visible within a quarter of releases.
Review the count of reopened tickets after the next two releases. If it falls, keep going.
Repeat defect investigation sheet
One sheet, one row for each repeat bug. Columns run: ticket number, first fix commit, release shipped, release where it returned. Then come test added at fix time, staging against production data gap, hotfix merged back and the cause assigned. A summary box counts causes.
Open a blank worksheet to printQuestions owners ask
Why do fixed bugs reappear in the next release?
Usually because nothing checks the fix again, the test data hides the fault, or the release was built from a branch that lacks the patch. A timeline for one bug shows which. One page of dates, commit hashes and the tester’s name usually makes the weak link visible. A spreadsheet is all the tooling you need.
Do we need automated tests to stop repeat bugs?
Automation helps, but a written regression sheet run by hand also works at first. Automate the checks that run every release and rarely change.
How do we find out if a hotfix was lost?
Search the release branch for the hotfix commit, or ask Git to list commits in production that are missing from development. Do it before each build.
Who owns regression checks?
The developer who fixes the bug writes the check, and the QA or product owner confirms it runs before release. Shared ownership usually means none.