Article summary
No, this is not a nature blog about some new weird discovery. This is about the system you are writing. Although we all strive for 100% perfect bug-free software, some bugs will creep in. It’s ideal to stomp on the bug as soon as it’s found. However, that often won’t happen with all the conflicts of developing new features versus fixing old systems.
So after some time, your backlog might start to have many bugs logged in it. What to do about that bug list?
Ignore them.
If the customers, clients, and/or stakeholders are not pushing you to fix the bugs, then it’s likely they aren’t a priority.
Maybe they are “tester only” bugs that only happen when triple-clicking a button on a modal that is full of 300 capital Ms. Or it could only happen on FF on an iPad. (If so, maybe look into why are you testing FF on an iPad?)
It could be a bug that only a keen-eyed customer paying detailed attention would notice like a typo or a small overlap of a scrollbar. There’s no effect on how the program works, just a minor cosmetic issue that doesn’t impact functionality.
The bug list will pile up, your backlog can look messy, and stakeholders might ask why there are 55 bugs in that backlog. But, if you can answer these questions with a valid reason you haven’t fixed them, then they could stay there.
Retest them.
If there is a lull in the development cycle, then you could use this time to retest the bugs to see if they are still in the system. Perhaps a rewrite of a component has also fixed the bug. Or, maybe a redesign of part of the system means the bug can no longer happen.
Before doing this, check for changes around the bug area. Otherwise, you could waste your time confirming that bugs are still there in a part of the system untouched since the initial bug report.
Icebox them.
You could set a period (dependent on the age of the project) where any bugs older than, for example, six months, are moved to an Icebox column. If anyone ever wants to see if the issue was reported, there will be a historical record of them. But, they will no longer show up in that alarming stat report.
Learn from them.
Look through the bugs and see if you see any patterns. Are there several “goes wrong when the page refreshed” issues? In that case, start testing for that. Is testing focused on the wrong areas or the wrong sort of issues? Could it be better aimed at areas where issues are of most concern to the business?
Bugs can cause frustration, alarm, and finger-pointing. Or they can serve as an opportunity to learn something and make your development process better.