Strategy to handle legacy bugs and developers tend to deny responsibility
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.
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.