Since when opening bugs becomes a counterproductive?

by Gunnar Kudrjavets on January 29, 2010

Feeds from Gunnar

Here’s one everlasting problem from real life what I and my colleagues are constantly trying to solve efficiently. The problem statement is very simple – when is the right time to stop looking for bugs in specific component if we know that the component will be obsolete in a small number of months? Yes, I know that all the software becomes obsolete after some period of time, but also not all the releases are ground-up rewrites i.e., the noticeable amount of the code base stays the same. Also, please note that this is different from the classical question about when it’s the right time to stop testing at all ;-)


Let me give you a manifestation of this situation IRL. Assume that you have a component C what you’re trying to test and you know that during the next milestone it’ll be rewritten or major design changes which will affect the majority of the code base will be applied to this component. At the same time you’re also shipping this component to the customers with the current release and you’ll need to support it for years to come.


The question is simple. Should you either:



  • Continue to hammer at the current implementation even after the shipping and try to find all the places where access violations, race conditions, resource leaks etc. may occur. Being informed and knowing about the existing bugs and their impact is always better then sailing in dark. The downside here is that probably all bugs you open will be resolved as “Won’t Fix” (unless it’s something groundbreaking), triage team’s time will be wasted, and people will start questioning if you’re working on right things.

  • Use the following rationale: “The code will change anyway, resources are always spare, and we should test the component so that it’s good enough for this release (Well, how do you quantify this and how “good enough for this release” is any different from our usual quality bar?). If the customer data will indicate that they’re having problems with the old implementation then we’ll fix bugs which are being discovered.” The downside here is that if everyone testing the component knows that you’re doing something which will be obsolete in a couple of months then it’s very clear that nobody will spending long hours trying to discover every little bug.

There are no easy answers to this question and in my experience every situation is pretty much unique and there are lots of factors to consider. Anyone cares to share how they approach this particular decision and what are the things involved in making the decision?

Random Posts

Leave a Comment

*