我们在一段时间前（大约 3 个月）开始使用 TFS 2013 作为错误跟踪器。在此之前，我们仅将 TFS 用作源代码控制（在另一个软件中执行错误跟踪）。目前我们已经开发了一些流程。我们将非常感谢任何有助于我们理解此过程是否正确的评论。所以，他们在这里：
基本信息：
- 我们正在开发一种大产品。
- 我们的团队有 5 名开发人员和 2 名 QA。
- 我们通常每 1-2 个月发布一次新版本。
- 我们有 1 周的冲刺。
这就是我们使用 TFS 的方式：
- 我们有一个团队项目和许多领域。每个区域代表产品的某个部分。
- 我们的团队项目使用 Scrum 2.2 模板。
- 在团队项目中，我们为每个版本创建一个“大”迭代（例如“Release 01.2014”、“Release 03.2014”），该迭代从上一次迭代结束开始，持续 1-2 个月。
- 我们使用 2 种标准工作项类型：任务和错误
- 所有错误和任务都属于适当的“大”迭代和区域。
- 我们以两种方式使用任务：作为任何改进和新功能的独立工作项，以及在修复错误时作为错误的子项。
- 为了监控当前情况，我们为 TWA 创建了一堆查询。其中一些是共享的（例如“Bugs new”、“Bugs for testing”、“Tasks in progress”等），其中一些是由每个 dev/QA 创建的（例如“My tasks in progress”、“My错误完成”等）。
以下是 Bug 的工作流程描述：
-->QA (or dev) creates a bug (State: New)
-->QA (or dev) assigns this bug to some dev (State: Approved)
-->When dev starts to fix a bug, he does the following:
---->changes state of bug to Committed
---->creates child task and changes its state to InProgress
-->When dev commits some code, that should fix the bug, he bounds checkin to task (created on previous step)
-->QA understands, that bug is fixed and ready for testing, when bug is in Committed state and EACH child task is in Done state
-->QA tests fixing of bug:
---->if bug is not fixed he changes state of bug to Approved
---->if bug is fixed he changes state of bug to Done
这个过程看起来不错，并且以某种方式起作用。但是独立任务存在一个问题，它是为改进和新功能而创建的。
这里是独立任务的过程描述：
-->QA (or dev) creates a task (State: ToDo)
-->QA (or dev) assigns this task to some dev (State: ToDo)
-->When dev starts working on this task, he changes its state to InProgress
-->When dev has finished working on task, he changes its state to Done
-->QA tests this task:
---->if new features work fine ?
---->if new features work with errors ?
这是主要问题：QA 如何将 Task 标记为通过或未通过测试？ 我们现在如何解决它：如果一切正常，QA 会用标签“关闭”标记测试任务，如果有一些错误，则会为任务创建子错误。但是以这种方式使用标签似乎并不好。
编辑还有一个问题：Bug/PBI 的哪个状态最适合状态，当 bug 被分配给开发人员，但他还没有开始处理这个 bug？
任何意见和建议将不胜感激。