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.