8 Questions to Ask before Fixing a Defect
Defect fixes can be costly and risky—sometimes moreso than the defects themselves. With a little insight, you can determine whether a defect should be fixed or left on the ash heap of history.
Every fixed defect is a link in the chain of quality. Numerous unfixed minor defects and cosmetic issues lead to doubt about the accuracy of the application’s more complex functionality, blemishing the entire product and possibly the company’s reputation.
There are some good reasons to fix a defect. Any defect in calculations, lost revenue, security, loss of life or injury, or a noticeable decrease in performance usually leave little doubt about their need for correction.
However, every code fix is a potential risk, increasing the possibility of generating new defects. This is especially true when fixing backlogged defects. These stale defects become more risky to fix because of the need to refamiliarize yourself with previously written code from people who may no longer be there. Additionally, the resources spent fixing backlog defects are in direct conflict with future development.
Not all defects are created equal, so careful thought should be applied before a defect is fixed. The goal isn’t to fix every reported defect; it’s to return value to the customer and profit to the company.
The “defect parallax effect” is where an issue appears to vary when viewed from different perspectives. Determining if a defect is worthy of fixing requires analysis from all possible usage scenarios, stakeholder positions, and consequences.
These questions can help in the decision-making process.
- Severity: What are the consequences when this issue arises?
- Probability: What is the likelihood that the problem will surface?
- Incidences: How many times has this issue been reported?
- Time: How long has the problem been in existence?
- Cost: What is the price for this fix? It’s the time needed to fix, deploy, and test, including updates to automation scripts and documentation.
- Risk: Is the fix risky enough to introduce new defects? Not only should the code complexity be taken into account, but also the competency of people doing the fixing, deploying, and testing.
- Delay: What potential work are you sacrificing in order to fix this problem?
- Reporter: Who found the defect? If it was your bosses’ boss or a high-profile customer, it may warrant a fix no matter your responses to the previous questions.
Most companies want their customers to be delighted all the time, but that’s unreasonable. Fixing every reported issue is irrational, so sometimes acceptance of software’s imperfections is a more reliable route to moving the product forward.
Your defect database is a report card on your software development process. Taking a more long-term approach to software quality is advisable. It’s better to spend the time fixing the root causes of the reported defects and obtaining qualified resources than fixing defects.
Break the mindset of “We never have enough time to do it right, but always enough time to do it over.”
Wondering what peoples response or action is when you decide that a bug will not be fixed. Do you leave in the backlog or close off?
Hi Paul. Good question. For the bugs you will not fix I’ve read pros and cons for both options. I’ve listed a few things to consider when deciding either to close them vs. having them remain in the backlog:
1. How you process your backlog - Are you repeatedly reviewing the same old bugs you know you’ll never fix which is consuming your limited time and resources? To optimize your day, closing these stale bugs and getting them off your plate could be an option.
2. The information you include when closing a bug - When you close a bug is the reason you’re closing it sufficiently captured? It should be. Not just capturing a generic reason of “Will Not Fix” but why you’re not fixing the bug. This provides an historical record of your decision.
3. How people write bugs – To avoid writing duplicate bugs do people query only the open bugs? You would also need to query the closed bugs that have a reason of “Will Not Fix”.
4. The metrics that you capture – If you capture metrics on bugs closed you’d want to be sure the metrics are granular enough to identify the reason the bug was closed so to clearly identify bugs fixed vs. bugs you closed as “Will Not Fix”.
5. Future perspective may change – Just because you close a bug doesn’t mean that someday in the future your perspective, circumstances or business needs will change and you’d want to fix a previously closed “Will Not Fix” bug. There is no reason why you can’t reopen a previously closed bug.
6. Team buy-in – The team should always weigh in on the decision to close a bug that will not be fixed. A problem shared is a problem halved.
Hope some of these points help you in your decision process.
Richard