When you look at the backlog of bugs for your product how does it make you feel? If you answered “good,” congratulations, you should feel proud. If your immediate reaction was to cringe and try not to think about it, then I’m sorry to say that you have a problem. However, I can offer you four words that may bring you some comfort: You are not alone.
I’ve seen it many times with many clients. When a company hires Applause to test their application, they typically provide a set of artifacts intended to help us get up to speed quickly: access to various project management software, a test suite, and more often than not, a large backlog of known issues. The latter is typically intended as a resource so our testing teams understand what bugs not to log when testers find them. Believe me when I tell you, some of these backlogs contained over 1,000 issues. Cringeworthy indeed.
A bug backlog kills time and delays finding new bugs
I won’t go into the reasons why your backlog might be so cumbersome. The root cause of a large known-issues list could be a symptom of myriad causes, ranging from a lack of resources to keep up with feature demand to bad processes or downright bad code. These contribute to an ever-growing bug backlog which can quickly suck even more time away from already tight sprint deadlines.
As a tester touring an application for the first time, there is nothing more agonizing than spending valuable time wading through an uncomfortably large known-issues list to ensure that bugs you have discovered haven’t already been reported. This wasted effort delays finding yet-to-be-discovered issues. This is particularly worrisome when testing on a tight deadline, and increases the risk of high-priority issues being missed.
,
Don’t despair: Analyze and quickly remedy your bad bug backlog
When faced with a daunting backlog, we often tell ourselves “It is what it is,” but I’ve never agreed with this self-talk. It’s more accurate to say “It is what we made it.” The bug backlog didn’t just appear out of thin air once we envisioned the project. It was made over time, growing slowly, the problem neglected until it became the monster it is today. But now, what can we do about it? The answer is simple. Let Applause’s teams analyze your bug backlog and help you shrink it to a more manageable level.
If needed, Applause testing teams can retest every bug in your backlog, closing any that are no longer reproducible and updating any that remain with new information and logs to help you to fix them. We often find that a good portion of these issues are no longer reproducible due to updates that have been made as part of a normal feature sprint. Sometimes we find that even the feature where the bug was first reported has been deprecated altogether.
,
Using crowdtesting to analyze bug backlogs for patterns helps thin the list
Once we’ve closed the bugs that can’t be reproduced, we can analyze the valid issues and look for patterns in the data that not only shrink the backlog further, but help prioritize a plan of attack for fixing them. Doing this, we often find that a portion of the bugs are the same or have the same root cause. We can then close these bugs in favor of one bug report that contains all the pertinent information.
We may also find cluster patterns where high percentages of the bugs in the backlog derive from one or two features in the application. With this information, you can prioritize these features in an upcoming sprint, or better yet, if you know that these features are already being scheduled for a complete overhaul soon, you can close them outright when the new code is released.
Best of all, with our crowdtesting model, we can usually tackle very large backlogs for you in a matter of days, so the next time you’re asked how your bug backlog makes you feel, you can honestly answer “Good.”
Learn more about how Applause Test Case Management can help you control the bug backlog.
4 min