工作事件中的bug和问题
使用典型的开发习惯，开发者和测试者可以从多种不同的资源中完成工作。项目计划工作时间表中的工作，例如开发代码和编写测试计划，单独的列表保持和在项目计划外的计划，项目经理可以设置aside buckets of time来允许团队的成员在其他的列表中工作，或者他们也可以创建单独的项目计划，不管在同一个开发资源中对多种不同类型的工作进行管理可能存在的错误可能性。
团队系统中的工作事件跟踪允许用户灵活的定制化的跟踪在一个单一库中跟踪所有的类型的工作，并且使得管理这些不同类型的任务变得更加简单，不同类型的工作事件可以被分离成为不同的工作事件查询来管理，然而，如果他们是在一个相同的团队项目中，那么为了开发者创建的一个工作事件列表将会有新的开发任务，与这个项目任务有关的研究任务，修复bug任务等等，所有的这些任务会在一个单独的列表中区分出优先顺序。
测试
在前面的部分已经暗示过，测试者作为工作事件跟踪的结果在整个开发生命周期的整合中也有着重要的意义。测试者使用Visual Studio Team Edition for Software Testers可以完全访问Team Explorer从而查看他们自己的工作项目。例如，许多的项目要求创建手动测试事件，这些手动测试在Visual Studio Team Edition for Software Testers中被创建和管理，哪些测试用例需要被写入，以及那些测试用例的状态可以在工作事件跟踪系统中被跟踪。项目经理可以想管理和跟踪开发人员一样为了跟踪和管理测试组的效果同步数据。测试者根据开发者相同的处理，然后进行工作事件跟踪系统的任务委派。他们开发的手动测试用例将会提交到资源控制中，并且以一个与开发者代码相同的风格与工作事件相结合。
此外，测试者可以对编译的报道进行评论，从而找到那些已经测试完成的特性。作为开发者完成了开发的任务并且联合他们在工作项目中提交，这些关系在Team Foundation Server中存储，在编译处理过程中，这些工作事件的状态可以升级的指出他们完成的和在编译中包括的。在编译中所包括的那些事件已经是测试过的。在运行一个编译报告时，一个软件测试者将会清楚的知晓哪些工作事件是他们应该集中精力进行测试的，那些工作事件可能是必须的条件，bugs或者一些其他类型的任务。
然而，这只是个开始，作为测试者发现了系统的问题，他们可以在Team Foundation Server上报告这个反馈，使用工作事件，可以报告一个“Bug”或者相似的用户工作事件，测试者可以记录他们在工作中需要做的工作。这些新的“Bug”任务可以发送到一个开发领导，或者一个项目经理，或者是一个恰当的开发者那里，并且在处理模板中指定。此外，测试者可以设置一个工作事件关系，用于将有bug的工作事件连接到测试者所测试的原始的工作事件。
当开发者收到一个工作事件分配和定位错误地址后，开发者将继续工作流，开发者定位“错误”的工作事件将会出现在编译报告中，已使得测试团队可以验证这个错误得修复情况。Team Foundation Server作为一个后端得处理来进行整个处理，需求，开发任务和错误得报告，同时问题得确定可以被绑定在一起。这些事件可以在团队成员得最小影响下被描述和报告出来。
报告和工作事件数据库
Visual Studio Team System 和 Team Foundation Server得一个重要得方面就是一个工作事件的存储。所有的工作事件数据是由Microsoft SQL Server 2005数据库中的Team Foundation Server 维护的。此外，在这个方法的灵活性，稳定性和可测量性方面，在报告观点上都有着极大的价值。
作为基于一个特定的处理模板的团队工程的创建的结果，项目的入口被适当的报告出来。在开发项目中感兴趣的个体，不可以直接的卷入，可以运行报告去得到开发任务的状态，bug数量和其他的工作事件或者非工作事件报告。这在企业价值和IT管理方面方面有着很大的价值，在WSS团队的项目门户站点中包括一个Web part去允许查看在SQL Reporting Services中创建的报告。这个报告在站点中可以通过方法模板进行定制化。
工作事件定制化
由Visual Studio 组系统所提供的处理模版被高度的定制化。独立的组织和群能够修改几乎所有方面的方法，来与他们自己的需求达到一致。实际上，某些组织将打算要创建多重的自定义处理模版类型，以使其适合不同的发展项目类型。
在一个更高的层次，处理模版体系结构提供了以下几个范围的定制化：
1. 分类结构服务 (CSS)—为组项目定义了结构，包含为项目生命周期和项目层次的反复定义。
2. 组安全服务 (GSS)—定义了初始组和处理模版的许可。
3. 报表—定义了由处理过程所提供的报告的标准。
4. 来源控制 (SCC)—定义了许可和为来源控制提供的可用的记录。
5. Windows 共享点服务 (WSS)—定义了文档模版，文档库，以及处理指导。
6. 工作事件 (Currituck)—定义了类型和工作事件的特征，工作事件查询，为一个新的组项目提供一个默认的列表或者一些工作事件，以及从工作事件到Microsoft Project的映射。
在你的处理模版之中，工作事件跟踪系统可以自发的实现高度定制化。你拥有自定义工作事件类型的能力，或者根据一个典型的具体情况而定，在现有的程序基础上重定义工作事件类型。举个例子来说，代替了在MSF中进行灵活软件开发所提供的默认的五个工作事件，取而代之的是，你可以定义工作任务类型为，“需求”，“bugs”，“风险”和“问题”。你甚至可以为工作事件取任何你喜欢的名字；举个例子来说，也许你喜欢“缺点”更甚于“Bug”。你可以更改很多，或者只改其中的一小部分的工作事件的类型作为你用途的需要。
另外，你实际上可以改变工作事件定义的内容。举个例子来说，你可能设定如下，一个特殊的工作事件类型需要额外的属性，用这种方法来使你的环境更加实用。 增加一个Severity 领域到你的"缺点" 工作事件类型是与编辑一个XML文件一样简单的。 另外，你可能为你的新领域(例如，Very Severe 和 Unimportant)制定正确的值。你同样可以设定这个领域怎样才能被看见，而且若修改值的话需要获得许可。 除此之外，基本的流程是被支持的，而且将会允许组建立服务以使它能够自动地影响领域中的值作为你的工作事件，从而在他们的生命周期中传输。
作为不同领域的工作事件被普遍关联的一个例子来说，下面的列表包含了使用了MSF为灵活软件开发定义的"Bug"工作事件默认的领域，测试第二版： Id, Title, Assigned To, Area Path, Iteration Path, History, Reason, Changed Date, Changed By, Created Date, Created By, Summary, Issue, State Change Date, Activated Date, Activated By, Resolved Date, Resolved By, Closed Date, Closed By, Priority, Triage, Test Name, Test Id, Test Path, Found In, 和 Integration Build.能够注意到与所有领域一起可能会为工作事件保存数据这一点是非常好的，他们之中有很多是在标准处理过程中自动地捕获数据，而没有为组成员提供扩展性的数据入口。
1
