Oftentimes, QA teams ignore low priority bugs. But with time, these bugs gain more importance, both internally and externally. Let’s take a look at how these low priority bugs can negatively impact your product and organization and how you can address them with processes.
Does this situation sound familiar? Your team just developed a new cool feature to automate emails, but after testing, your quality assurance team found three critical issues caused by merging with a branch from another team. They also found two major bugs that were caused because requirements were lost in emails and seven minor bugs that do not affect the core feature. Some of these minor issues are layout bugs. Some exist only in corner cases, and others are usability suggestions.
NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.
We need to remember that the release is in two days, so the whole team is now thrown into fixing madness. Due to time constraints, not everything will be fixed. Some bugs will be characterized by developers as “not a serious issue”, closed by the UX team as “nice to have”, or moved into a backlog by the product owner with a comment “to be fixed in the next version”.
Let’s be realistic – some of them will be fixed. But, many of them will land in a dark pit of backlog and will never be revisited unless the CEO or your major client will complain about them. The reason is simple and justified – on the horizon, there are five more big features to be developed. This dark, forgotten place with low priority issues, I call the bug tail.
Do not get me wrong. I do not believe in fixing all existing bugs and neither should you. Some bugs are too costly to fix, some of them not worth the time. And, your team can still release successful features without fixing them. But, let’s see how they impact you.
Long Term Negative Impact of Bug Tail
Internally
Let’s move forward in time two years. A new QA engineer or developer is hired. During the on-boarding process, in the first two hours, they find ten small bugs in your product. They start asking people around “should this be happening?”, and they even submit tickets in Jira. But, those tickets are closed right away with an annotation “known issue or won’t be fixed”. The message the new employee gets is: “We do not care about the quality of our product“. So he starts to ask himself: “Why should I?“. Also, this process repeats for every hired person, thus creating informational noise.
Next, QA engineers will stumble onto these small bugs, in everyday work: when testing or writing automated tests. To take into account existing bugs, developers will create new code with hacky workarounds – which will cost them time.
Please believe me when I say people from your team care about quality and doing a good job. In the long run, the more small issues you have, the more frustrated your employees are. If a fix is easy to introduce, but there will be no time for it, it will be even more challenging. Does their company give them a visible reason to create the best code and the best solutions? For some of them, this may be the last straw to start looking for another, more quality-oriented job. Now you’ve lost an experienced employee and lost some money.
Externally
The same day two years from now, a sales representative is presenting your awesome app to a potential big client. Everything works, but during a trial period, a potential client spots five bugs. Of course, sales will have a historical and logical explanation about why they are not bugs and why the app will work anyway. Still, something does not feel right for a potential big client.
One week later, a small startup launches the same service. They do not have all those fancy features and integrations your app has. But because of that, they feel good. They polished the core functionality of their product. From this day forward, your company will start to lose money, because some of the potential clients will choose this new, competitive service, for a simple reason – it feels better. It does not matter that their functionality is limited in comparison to yours.
Bug tail is not the most important factor in software development. But, it has an influence that should not be neglected. It affects how your employees feel about your product – if they call it utter garbage or treat it as their sweet child. It creates informational chaos when again and again people talk about those issues. In the end, if not addressed, the feeling of quality of your product by your clients will decrease.
The Solution
Luckily your adversary can be your ally and it will not cost you that much time or money. The trick here is to consider bug tail when creating your development process. Here are a few cheap ways to do it.
One Time Action
Let the new QA play with your product for a few hours. All the issues he will find, your client will find in the first week. All such obvious bugs should be eliminated. This will create a much better impression for everybody who will start the adventure with your app.
Create a Parallel Process
We are so accustomed to a delivery process, that anything which does not fit this purpose is rejected. But you do not need much. You can start with one developer who is focused only on fixing small issues in your app once per week or two weeks. Too much? Once per month? Any time of taking care of them is better than nothing.
Create Nests of Bugs
Instead of throwing bugs into a dark pit, ask PMs to structure them in your bug tracking system around features. Amanda will be working on a new export function? Cool, we already have a list of bugs that exist in the export module, maybe she can spend half of the day fixing them because she will already dive into its code?
Throw New Developers Into The Pit
Do you have a new developer joining your team? What is the better way for them to know the system than to fix some old issues in different modules! They will have hundreds of questions but in the end, they will be ready to write new code with an understanding of how your product works.
Bring Them Into a Sprint
Make a simple rule – every sprint should consist of one, two, number x of small bugs to be fixed.
The Final Goal of Cutting Bug Tail
The goal is not to fix all low priority issues in the long term. The goal is not to spend one month refactoring for a 1% speed increase. Or, to create improvement which will be used by 0.5% of users. Fixed estimations should be done because otherwise, your costs in time/money will dim advantages. The most important factors to consider are:
- How often does an end-user encounter the bug?
- How do developers or QAs feel about addressing this bug? You can even introduce your own metric here.
- How much time or how many story points will it take?
- What is the risk of creating a more serious, regression bug?
The ultimate goal is to show the client and members of your team that you care. In the long run, the client will see you are fixing small issues. For them, this can be more visible than a new feature rarely used. This way you build positive association and loyalty. You also get a product that is easier to maintain – as those fixes will force local refactorings or updates of libraries or removing old code. You get a happier team, which is a more productive team, delivering a better product.
