我们将Vs2008/2010与TFS 2010一起用于源代码管理，因为它还允许我们创建可用于项目管理的自定义工作项类型，例如产品积压项和冲刺积压项。
一个没有被机器跟踪的项目是为发布候选者构建回归测试任务。我们的回归测试部分是自动化的，部分是手动的，手动部分可能需要几天时间。目前，我们使用excel电子表格列出所有测试用例，然后测试人员只需填写结果和注释。
我一直建议创建一个构建回归测试模板，其中包含每个测试用例、默认所有者，然后当我们想对构建进行回归测试时，我们可以自动为模板中的每个测试创建工作项。
我的论点是，如果回归测试工作对项目来说是强制性的，并且应该跟踪结果，那么编写额外的TFS工作项是有意义的，特别是因为这些工作项可以包含估计值，让管理者知道还有多少重新测试时间。
反对这一点的理由是，我们已经有了高级别的工作项来捕获整个项目测试需求，而回归测试基本上是一个"重新测试"，所以新的工作项是重复的。
我的问题是：还有人在做这样的事吗？使用TFS跟踪未完成的重新测试任务是否合理？
注意：我们没有Visual Studio Test Professional
我认为采用您建议的解决方案是合理的。"测试任务"应该有另一种工作项类型，可以作为子项链接到测试需求工作项。正如您所说，这样做可以跟踪结果、进度、报告等。您还可以将其他字段（如内部版本号、测试者、测试日期等）添加到历史记录的工作项类型中，这是仅使用一种测试需求工作项类型无法完成的。
从本质上讲，您的建议是在Microsoft.TeamFoundation.TestManagement.Client.dll的ITestResult对象中完成的。