Strategy to handle legacy bugs

Question

There are a number of new developers and testers in our team. When the testers are testing the new features the developers built, they are finding a number of issues, which is not strictly in the scope of the feature. As a result the developers tend to deny responsibility and the bugs are going to the production bug tracking system. These bugs are worked by another set of developers and the fix rate is very slow. As a result, we are not really improving quality sprint by sprint, but just accumulating technical debt.

How is this situation normally tackled?

Edit: My question is not really how a tester will handle the situation so that it wont affect him/her. The question is more like how can we tackle the situation at the process level so that the quality of the software can be improved sprint by sprint.

Answer 1

The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of:

• something introduced by the changes
• something that was there before and doesn't have much if any impact on the changes
• something that was there before and has a major negative impact on the changes

The developers in the team need to fix the items that were there beforehand and negatively impact their work, as well as the problems they accidentally introduce.

That's the easy part.

Now for the more difficult side - realistically, most of the pre-existing bugs your test team finds won't have a major impact on the feature, and it really isn't the feature developers' role to fix them. In this case, they absolutely need to go into the main issue tracking system with whatever bug advocacy you're able to provide.

Some strategies you might try:

• Note any major customers who could be impacted. In my experience, existing bugs surfaced by new development are usually the kind of thing that isn't terribly severe - but if something that had little or no impact before the feature is likely to upset your biggest customer and you know that customer is planning to use the new feature, you can legitimately increase the priority of the issue - just make sure to note that this customer will be affected. Even if the issue is not fixed, the fact that it's in the issue tracking system will boost your team's credibility when the customer demands to know why this wasn't found in testing.
• Evaluate priority and severity fairly. By this I mean don't just rank it highly because your team wants it fixed. This will harm your team's credibility.
• Look for possible reasons why the issue hasn't been caught until now. If it has a workaround, there's a strong possibility your customers know about it and just haven't said anything. In my experience you might get 1 in 10 customers complaining about a problem (if you're lucky - it's more like 1 in 100 or more for a lot of places). Unhappy customers often don't say anything, they just look elsewhere.

Your goal is to give the team that prioritizes bug fixes reasons to fix your bugs (and if everyone is doing this, all the bugs will have sound reasons for why they should be fixed and the priority level they have).

Ultimately, you're not actually increasing technical debt, you're exposing it. This is better than not exposing it.

Answer 2

Generally, it us a tester's job to report any defect and enhancement that is believed to improve customer's aim with the product. Sometimes, the tester finds missing links in the analysis of the requirement ir proposes to enhance a feature. In this case, I think that the development team should not take these issues before gettibg approval from the project manager, who is the one that will decide if the issues should be considered at this stage or pushed for later. Thus, the best way is to work only on approvals

Answer 3

Expected result stating the business reason of the change or enhancement. In my perspective, it all depends on the release state of the project, the severity of the issue versus the impact it would have on the current project. Issues with high impact and high severity must be closely addressed at a release deadline.

Answer 4

If the test team is finding that many then it is possible their focus is not entirely on the new functionality. A common strategy is to focus the test team on the new functionality and look at reporting only issues which arise from interactions between old functionality and new functionality, or issues which will impact the new functionality you are delivering.

If you are unwilling to take that responsibility yourself then negotiate it with the next level of management. With something like ie; "The testers are finding a lot of medium level issues which have nothing to do with our current delivery schedule. To meet the schedule I plan to focus our testers on our current priorities and in the short term this may mean some lower priority issues related to [legacy] will go unreported."

The fact is that logging and reporting low and medium priority issues accurately and then assessing them has a cost. Since you cannot (in many senses) charge that cost to another project you really have to focus in on what is important to your delivery.

You may find the next level is unwilling to commit to any decision or accept any responsibility or has a very limited understanding of the reality of the situation. If that is the case you will have to make the call independently.