Andy Glover and Matt Archer published a nice infographic about “Reasons why you fix bugs as soon as you find them”. The topic may seem obvious to some, but this is a real issue I encountered. I’d like to comment the reasons mentioned using my own experience as a QA.
– unfixed bugs camouflage other bugs
=> I agree in theory, but don’t have vivid memory about such a case. (I do have lots about bugs hiding bugs, but usually those were seen as major and fixed asap)
– unfixed bugs suggest quality isn’t important
=> QA are aware that doing a bug-free software is impossible and that accepting some bugs is part of the game, but it is quite discouraging when it become to frequent. In this case, QA start to wonder why they are hunting bugs in the first place.
– discussing unfixed bugs is a waste of time (planning, replanning, rediscovering…)
=> So true. When you end up having repetitive “bugs triage meeting” requested by the QA so that their “known and annoying bugs” could be fixed, you should realize you are losing your time and fixing those issues would maybe have been quicker.
– unfixed bugs leads to dupplicate effort (risk to report the same bug again and again)
=> So true. Demotivating for the whole team when the new hired QA comes proudly with a bug and we all say “oh, this bug ! that’s an old friend…. we’ve know him for 3 years”
– unfixed bugs leads to unreliable metrics (if you measure “open issues”)
=> I am not into metrics to much. No comment.
– unfixed bugs distract the entire team
=> True. Unfixed bugs become a sort of “common knowledge” that everyone in the team should master whereas we should focus on knowing how the soft works (not how it fails)
– unfixed bugs hinder short-notice releases
=> I did not met the problem. Usually “unfixed bugs” were not major enough for me to block delivery (that’s why they ware “accepted” in the product in the first place)
– unfixed bugs leads to inacurate estimates
=> agree. Although I did not witness this so much.
– fixing familiar code is easier than unfamiliar code
=> Sure. After a while, a buggy piece of code becomes impossible to fix by the team.
– fixing a bug today costs less than tomorrow
=> that is a summary/consequence of the last 9 points
In addition I would like to add that unfixed bugs are a mess for QA team doing automation. How do you deal with an automated test case that is testing a (probably partly) broken feature ? Do you run the test and class it as “KO but we know it” ? Do you skip it ? (but then the test case might become obsolete very soon”). Whatever choice you make, it leads to a more complex automation framework.
