一、团队有效协作的基石——Team Foundation Server

　　敏捷开发强调人与人之间的有效沟通和紧密的团队协作。对于测试团队和测试人员而言，首先应该需要考虑的是：如何让测试工作更有效的集成整个敏捷开发的活动中去？而不是将测试工作仅作为一个“附件”或者可有可无的副产品。当然，这会受到团队组织形式和开发过程的限制，例如：采用功能小组模型的团队，所有角色成员（PM、开发人员、测试人员）隶属于同一个功能团队，客观上其沟通就更为方便；而对于采用纵向按职能划分团队的公司而言，测试和开发在隶属关系上是分开的，相对在沟通上障碍就会更多些。无论是哪种组织形式，好的工具能帮助促进和统一各个角色间的信息互通和共享，而不是要让他们彼此之间更为孤立、工作在各自的一亩三分地（Silo）中。Team Foundation Server 2010（以下简称为TFS 2010）就是这样的工具，作为整个团队协作的核心，它统一了团队不同角色信息、实现了信息之间的有效互联互通、彼此之间的共享和关联，例如：TFS 2010 定义6 种默认的工作项类型，如下图所示。

　　其中，Test Case 和 Shared Steps 是2010专门为测试新加入的。不要小看这些工作项，它们之间有着丰富的关联关系，这种关系背后所代表是角色之间的关系。对于测试而言，它将测试和团队紧密的结合在一起。例如：Test Case 工作项用来详细定义和管理测试用例，它还可以和User Story 相关联，也就是将测试和用户需求进行了关联，用户可以从需求追溯到覆盖的它的测试用例，这背后体现的是测试人员和需求人员/PM 的协作；Test Case 还可以与Bug关联，通过这种关联可以挖掘出哪些 Bug 被测试用例覆盖，哪些还没有，这种关联体现了测试人员与开发人员的写作，如果是自动化测试用例，则体现了手工测试人员和自动化工程师的协作 ；Bug 还可以可以和签入集（Change-set）关联，可以找到为了修复Bug，开发人员修改过哪些产品代码，这体现了测试人员和开发的关联。

　　敏捷开发频繁的迭代和较短的迭代周期，对项目管理的精确性、透明性和可见性都提出了更高的要求， 尤其对于那些项目复杂和人员较多的团队。Task 是另一个重要的工作项类型，它用于管理开发过过程中的所有任务项，包括：开发、测试以及需求等任务，统一管理开发中的所有任务，统一计算项目的开销和剩余工作量等。例如，项目的燃尽图就是由它产生出来的。现在，人们虽然在理论和概念上已经非常认同软件测试的在工程中的重要地位，但在具体实际操作中，测试却仍然被看作是低于开发和需求分析等的“二等公民”。当然这是由于多方面的综合因素造成的，从管理技术角度讲，这是由于测试工作本身缺乏可度量性和可见性，从导致了测试工作的透明性的缺失，团队往往看不到测试工作的进度和所带来的成果，从而意识不到测试的真正作用。对于测试人员自身而言，缺乏可度量性也让自己无法对工作进度准确把握，进而失去了对自己工作的目标感和认同感。将测试工作同其他工作一样的用Task 工作项管理起来，增加了它的可度量性和可见性。将测试工作和其它任务一起统筹，时刻确保测试被作为整体中的一部分进行考虑，所有的测试任务都被作为 Task 工作项记录下来，例如：编写测试计划、设计测试用例、自动化测试用例等等，每项任务都有三个默认时间估计数据需要填写，它们是：Original Estimate、Remaining 和Completed，分别代表了任务的预估时间、剩余工作量和完成工作量。