You have a couple of ways you can go about this sort of thing. If you spot a problem in something you have worked on before, you could:
- Fix the problem as a part of the task you are working on - refactoring dependencies to ensure your current task completes successfully.
- Log a bug, and provide estimates to fix it in your issue tracker. Then prioritize the task so that you either,
- complete the dependent task first, or
- complete the current task with tests showing an error, then go on to fix the bug you've logged, and on completion wait for tests in both cases to pass before checking it all in.
Personally I'm not in favour of leaving things in error while fixing other things. If the bug is new, and it's something in a dependency, then I simply fix the problem as a part of the task that I am working on. Once a task is complete, it's complete, and if it has a bug, it has a bug. Hopefully your testing avoids this situation, but if your tests still pass, then the prior task should be finished, closed, and left alone.
If you have made your tasks very granular, then you need to ensure that you have dealt with dependency items first. If you have two tasks with common dependency, you might complete the dependency in one task so that it is available when you move onto the next task. So by effectively completing tasks, You shouldn't need to worry about jumping back and forth between two tasks. It should just be a case of logging a bug, or fixing it as a necessary part of the thing you might be working on at the time.
Yes, this could all mess with your estimates, but if this is something that happens often and you are using Evidence Based Scheduling, then your estimations will all work out fine (statistically) after a short while, so I wouldn't worry to much about it. :-)