Duplicate bug detection
When a new bug is filed, have the system search the tracker for existing reports of the same problem by meaning rather than keywords, and show the likely matches.
How it works
Duplicate reports waste effort twice: once when the duplicate is investigated, and again when it is merged. Duplicate detection has been researched for years, and keyword-based duplicate suggestions are common in trackers; matching by meaning is newer. It embeds each report's title, description and stack trace as a vector and find the closest existing reports, which catches duplicates written in completely different words. A model can then compare the top candidates with the new report and explain the likely relationship: same bug, same symptom with a different cause, or related but distinct. Matches are shown to the reporter or triager, who decides.
When to use it
Large trackers with many reporters; products with public bug reporting or support-originated reports; after a release, when the same problem gets reported many times in quick succession; and when cleaning up an old backlog.
Limitations
Similar descriptions don't mean the same cause: the system will propose plausible duplicates that are different bugs, and closing them as duplicates loses the second bug. Reports that are vague match too many things to be useful. It works poorly on a young or small tracker with little to compare against.
Watch for
Two checkout crash reports match closely, but one is on a new app version with a different cause, and closing it as a duplicate leaves the new crash untracked. When the original is fixed, re-test each merged report’s own steps before closing them.
What you still own
The decision to mark something as a duplicate, and checking the cause rather than just the symptom when it matters.
Cite this
Qlarify Labs. (2026). Duplicate bug detection. Retrieved from https://labs.qlarify.fi/ai-in-testing/duplicate-bug-detection