It's obvious why you should track ongoing bugs. It's not at all obvious to me why you should track solved bugs. If a bug is solved, then just email the person who submitted it, delete the bug once they're happy, and maybe give your boss a thumbs up. Despite this, every bug-tracking guide I've seen suggests to track whether or not a bug is solved. For example, point #4 here suggests it.
So, what are the benefits of retaining a record of solved bugs? Is this standard practice? If so, why?
In addition to Thomas' answer, a bug report that leads to a code change is just as much a part of your code's history as the requirements specifications, architecture documents, customer change requests, etc.
Another way to look at it - would you delete the requirements documentation after having successfully implemented a feature in the code, or would you leave these so that you (or other developers in future) have some chance at being able to discover why the code exists and are able to validate that the code actually does what its users/stakeholders have asked for?
Ideally a bug report will contain a lot of valuable information for future developers digging into the code to learn when and why a particular line might have changed. For example - Who reported the bug and when; The circumstances around the bug; How to reproduce it; Root-cause analysis; Some discussion with stakeholders on the validity of the bug; along with any other potentially relevant context.
As far as standard practice is concerned, I would also expect developers raising a pull/merge request for a bug to explicitly reference the ID of the bug in their commit message(s) and/or the PR itself so that the source control history also provides breadcrumbs to the bug database.
Future developers having the source/commit history can use this to relate individual lines of code back to the original thought processes and reasoning behind why that code had been changed by following breadcrumbs like a Bug ID.
Otherwise if the bug report is deleted then all the valuable investigation, discussion, analysis and reasoning is lost along with it.
In addition to the other answers, the practicalities of software production process also influence this:
Bug fixes are usually not immediately put into production. Often it can be weeks or months before the new version reaches every user. In the meanwhile, the bug can get reported multiple times, so it is important to be able to quickly find it, determine that it is the same issue and that a fix has already been made.
Bug fixes are not always correct on the first try, or they can introduce new problems. Then you need to rework the bug fix, and it is important to have all information available on how it was originally detected and tested for.
It depends on what you're going to do with the data. There are plenty of things that you can do if you keep track of resolved issues.
From a product quality perspective, you can keep track of regressions or reintroduced issues. If you've fixed a bug once, fix it, and then get reports of the same issue occurring again, you may have introduced a regression. Understanding when and why you're introducing regressions can help you to prevent them.
You can also keep track of metrics like the source of reports to determine if issues are being found internally or externally, how frequently new issues are being reported, or how long it takes to resolve an issue once one is reported. These can be useful process quality metrics.
Not all organizations will need or want to take advantage of this data. But using an electronic defect tracking tool and having otherwise good habits around recording issues and appropriate metadata would make it easier to do analytics in the future should you want to.
Traceability - your code change is linked to a bug report, making it clear why it was done. Ideally, the bug report is linked to whatever requirement was not met or the test specification of the test that was red
You want to be able to reliably answer the question "was the bug fixed?" a few weeks from now. Ideally, by pointing at the change and also a green test case
Similar bugs found in other projects can benefit from your solution
Your SW will be out for testing in different versions, and you will get bug reports for older SW - it's good to know a bug is known, and fixed, in newer versions so you don't waste time.
When a regression happens, you will have an easier time identifying where in the code something broke. Could be a bad merge, or a new change, but regressions happen from time to time.
Often there is a good reason for a code change, as shown by the bug report, but a year later the reason is forgotten. Someone spots the bug fix code, thinks it is unnecessary complicated, and removes it. Then comes a new bug report and this repeats.
Having fixed bug reports available may help preventing this. (Although adding comments why your code does something unusual should work better).
Aside from everything else that’s been mentioned, having a list of resolved bugs since the last release of the software is actually kind of critical for being able to write good release notes. Users expect to see a list of what was fixed, and if you don’t keep track of what was fixed, the best you can do is something really vague like ‘Numerous bug fixes’.
This specific aspect obviously does not matter as much if you’re using a continuous-delivery model without user-facing versions, but there’s a lot less software using such a release model than there is that uses a traditional fixed release model.
Another reason is to track what ”areas” (being deliberately vague here, but excluding blaming people or micromanagement as a valid motivation) of your codebase introduce the most bugs.
For example, we once had a longstanding small-ish feature that was involved in 40% of our team’s customer-identified bugs.
This type of hotspot may have architectural issues or excess technical debt needing to be addressed at some point.
Likewise I once met someone who had had a fast track promotion from a beginner tester in a videogame company by having the insight to apply statistics to show which GPU families were most involved in which bug classes thus allowing better prioritization.
As another example, you may want to look at browser releases involved in server side errors in order to determine any recurring patterns.
These are concerns that outlive any particular bug.
In addition to the excellent answers given already, another reason to consider keeping the resolved bug/issue reports would be that the organization you're working for may have audit requirements for the SDLC, especially, if you're in a highly regulated environment.
In any work for pay it can also be used for time tracking and resourcing.
If you do the work you track the work so the boss knows it's been done and about how long it took.
If you don't do this you risk a project with time allocated only for new features and anyone who isn't adding them looking like dead weight.
Fundamentally, if you are tracking ongoing bugs then you have entries in a record. You do not just remove existing entries from a record because you think it isn't useful anymore. That defeats the very purpose of having a record and is fundamentally bad practice. Records exist because you never know when or why you might need the info in the future. You simply do not go around selectively removing entries. Imagine if a doctor erased the fact someone had cancer from their medical history after they were successfully treated. After all, the problem is solved, right?
You should not need a reason other than this. It doesn't matter if you can't foresee any benefits to tracking resolved bugs because the fact is that the ongoing bug reports already exist and you should not be removing them from the record. Since records should not be left hanging, at minimum, when something is no longer being updated it should be recorded as such. It just so happens a resolved bug report is equivalent to that.
Frankly, an entry saying that the status of a bug will no longer be tracked without stating whether not it was actually fixed, whether or not it will ever be fixed, is more acceptable than going around wiping resolved bugs from the record.
This was only mentioned as an aside in other answers, but:
You implement a test verifying that the bug is gone, with a link to the original bug description, analysis and solution. That test becomes a permanent part of the test suite.
Some bugs can re-occur. As a trivial but real-world example, a poor architecture demands that when you change x you also have to manually change y (there is no automatism for it); the next time somebody changes x without reading the documentation the test fails before the error is shipped. Then it is nice if there is documentation what the test was for, what the root cause is and how to fix it. This is most valuable if a bug like memory corruption manifests only sporadically in unpredictable ways but its cause can be reliably pin-pointed by the test (which e.g. verifies a buffer size).
In my opinion, the other answers provide a lot of good information, but they do not directly answer the question.
What are the benefits of tracking solved bugs?
One of the definitions of 'to track" in the Merriam-Webster dictionary is:
to observe or plot the moving path of (something, such as a spacecraft or missile) often instrumentally
Obviously, solved bugs do NOT have any path and any change.
However, they carry a lot of information with them (see the other answers) so they are used for all kinds of statistics, for all kinds of purposes. Mainly, they are used to see the work done in the past, and to see how new work progresses (or regresses) compared to older work.
These statistics are invaluable for tuning the advance of the project.
Those who fail to learn from the mistakes of their predecessors are destined to repeat them.
