Personally, I would have a way of uniquely identifying each test in your test suite. Then, you can specify in the RT report which test it is. The key is the unique indentifier for each test in the suite. Now, you don't have any difference between "bug tests" and "new dev tests". Frankly, in TDD, you fix bugs the way you write new code - with a test first. A bug report is a requirement. Instead of coming from the business analyst, it comes from the user. Either way, it's still a requirement.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

If you give each test a unique identifer, you can also track which tests handle which requirements. I know this would be useful for other reasons.

The ID should be something that is on the test-level without reference to which file or subsystem it deals with. Maybe, an order of creation? Then, the test suite is actually just a list of the individual test IDs that should be run?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested