白皮书：使用美科利TESTDIRECTOR来改进软件缺陷汇报和解决流程

作者简介

Punky McLemore是Hewlett-Packard公司的QA测试经理。在进入HP公司工作之前，McLemore曾是美国一家大型金融机构的QA测试经理，她负责为这家有着数十亿资产的企业管理所有的新应用的测试。该机构的QA部门拥有大约80名左右的测试专业人员，其美科利TestDirector®的用户数量达到了120名。McLemore有着16年的QA测试经验，她使用美科利产品的历史已达7年之久。

目录

作者简介

介绍

经验之谈

客户定制的软件质量缺陷汇报和解决流程
缺陷汇报

缺陷解决会议

缺陷修复

再次测试缺陷

缺陷状态定义

缺陷状态修改——用户操作的状态修改

将新的流程配置到测试自动化工具中 

介绍

在此份白皮书中，McLemore将和我们一起分享她在使用美科利TestDirector过程中所获取的独到见解和宝贵经验，其中包括使用TestDirector来支持各类大型项目、支持流程的建立和管理，以及如何便捷地改变和维护流程。此份白皮书将推出她所积累和总结的一些最佳实践，这是她作为项目主管，在一个耗时三年、广泛使用美科利TestDirector进行测试的项目——企业新的自动化外汇交易系统的测试——中所积累的最佳实践。

经验之谈

美科利TestDirector是一款在各个领域都能发挥强大功能的产品——特别是在跟踪问题和差异、管理缺陷解决流程等方面表现得尤为出色。为了帮助您更有效地运行流程，获取更好的结果，此份白皮书将为您展示一系列最佳实践，其它QA测试机构可以使用这些最佳实践来设计和优化他们自己的缺陷跟踪和解决流程。

此份白皮书中的内容是跟据McLemore在一个资产达数十亿的美国金融机构中任测试经理的工作经验基础上所撰写的。她在该机构中主要负责机构中所有新应用的测试，她所负责的其中一个项目是为公司的最新应用——自动化外汇交易系统——创建和运行一套复杂的缺陷跟踪和解决流程。在那之前，公司财政经理只能用电话来控制货币交易。有了该项系统，经纪人就可以通过电子手段，进行实时的货币交易。

由于要用电子手段来模拟一个手动流程，该团队认为可以通过研究手动系统来收集主要的需求。通过对经纪人的采访，查看交易者实际交易过程的录像，以及数个月来频繁召开“需求收集”会议，整体的业务需求情况逐渐形成。该系统必须做到精益求精，因为每个小失误都可能造成交易混乱，并引起上亿美元的损失。

当时，质量目标还不十分明确，因为他们没有现成的电子系统作为参照，目标制定缺乏一定的基础。因此，项目小组成员间默契的交流是该项目成功的关键。由于该项目涉及的人员遍及全球，且测试需要24x7不间断地执行，项目复杂程度可想而知。面对艰巨的任务，IT小组仍不断努力，期望能将开发环节中使用的手动流程实现自动化，以实现项目的既定目标。小组当时需要一种方法，可以让小组成员间就问题、缺陷、解决方案、项目进度，以及跟踪情况等内容进行顺畅地交流和沟通。他们也需要一种系统，它不仅需要具备高度的可靠性，还可以方便地进行客户定制，且能为遍及全球的用户提供支持功能。该系统必须操作便捷，使那些习惯进行手动流程操作的用户也能习惯使用这种自动化方案。（这一点也是小组成员努力想在系统里实现的一个目标，因为那些使用该系统的经纪人可能无法适应通过计算机来完成交易。）

小组在项目伊始使用了其它的一些自动化工具，但是却经历了数次的失败。随后，他们发现了美科利的解决方案。该金融机构的QA部门于是决定采用美科利的TestDirector来作为所有测试流程的基准。他们发现，TestDirector具备他们所需要的所有特性：

Ÿ          高度的可用性：美科利TestDirector不会崩溃。

Ÿ          优异的性能：响应快，足以应对来自亚洲、欧洲和澳大利亚的用户需求。

Ÿ          实用性：能便捷地根据用户需要进行客户化定制并使用。

由于小组对美科利WinRunner®工具有着良好的使用经验，因此采用美科利TestDirector来管理所有的功能和回归测试就成为一件自然而然、水到渠成的事。公司使用TestDirector来打造所有关于缺陷解决和进度安排的流程。他们把和应用有关的所有事件都在TestDirector中进行定义——公司的所有应用都被列为“项目”。货币交易项目的完成历时三年，取得了卓越的成果。

在软件开发生命周期（SDLC）的测试环节中所提到的所有差异、不足，以及其它异常的系统行为都根据公司新定义的问题汇报程序来进行记录、跟踪，并得到及时地解决。在美科利TestDirector中，差异被定义成为“一种测试过程中所发生的意外事件，或者是预期结果和实际结果不相符”。差异可能是一种缺陷，也可能是一种强化的需求，或新功能点的要求，或者是任何需要进行更正的问题。TestDirector中的“Defects”就是用于缺陷汇报的工具。

缺陷解决系统会跟踪项目中每个独立问题和差异——不仅仅是和应用有关的软件、硬件和软件问题——而且包括所有的流程问题，如每个步骤是由谁负责的，如何获取设备等等。此份白皮书的随后章节将描述McLemore为公司新的缺陷汇报和解决流程所定义的步骤。

客户定制的软件质量缺陷汇报和解决流程
 

软件质量评估（SQA）的缺陷流程图

实践证明，花费一定的时间和资源对所有的流程预先进行定义是非常重要的。只有展开全面彻底地规划，才能让缺陷汇报和解决流程提供有价值的信息，使IT流程合理化。以下部分所描述的步骤是在创建汇报流程、定义缺陷安全等级、记录缺陷状态和跟踪所有修改的过程中会被采用的一些步骤。

缺陷汇报

在SDLC中未被发现的所有和项目有关的差异及问题都将汇报到美科利TestDirector中。当在TestDirector中开放了一个缺陷问题，以下过程将随之跟上：

1．发布小组成员一旦收集到了足够的信息来重建或解释该情况，就会及时地在美科利TestDirector中登录一份缺陷报告。在TestDirector中，缺陷状态的默认设置是“New”。机构鼓励小组中的每个成员要及时地发布缺陷报告，争取最佳时间对缺陷进行调查和修复。

2．登录缺陷报告的成员必须根据该缺陷对应用和/或测试流程本身造成的影响，界定其安全性等级。安全性等级如下所列：

a.Show Stopper（严重阻滞）：某一区域无法展开工作，影响了部署的进程。相关工作都无法顺利进行。需要立即进行修复。

b.High（高级）：除了相关工作还能继续进行外，其它影响和Show Stopper相同。修复工作可以顺延到下一个阶段。

c.Medium（中级）：需要在部署之前尽快修复的一种缺陷。

d.Low（低级）：可以在下个发布（随后的项目）中进行修复的一种缺陷。

e.Enhancement（强化）：可以在任何时候去修复的改进建议。

3．缺陷描述具有一定的标准，这样就能确保涵盖该缺陷的所有相关信息。差异的详细情况可以相互结合，包括屏幕截图、相关的测试方案、选择标准，以及其它能帮助问题
解决的重要信息。

4．“Assign to（任务指派）”可以明确指出谁将负责展开最初的调查。在这一环节上，缺陷将指派给来自开发、环境支持、业务主管或产品经理等各方面的适当的团队主管。采用这种快速跟踪指派可以及时检查缺陷，甚至有可能在召开缺陷解决会议（下文将提到）之前就得到解决。如果无法决定指派给哪个团队来解决，缺陷将移交给项目经理。

5．如果发现差异的人员不是发布小组成员，该差异的具体信息将转交给测试主管，以便登录到美科利TestDirector中。

缺陷解决会议

测试阶段最浪费时间的无疑就是不能以有效的方式来应对缺陷，有些缺陷甚至被疏忽了。召开缺陷解决会议能确保所有的缺陷都能涉及并得到有效地解决。这种定期会议由来自开发、项目管理、产品管理、和项目相关的业务团队代表，以及测试主管共同参加，就缺陷问题展开讨论。系统的缺陷数量最高曾接近5000个，而每次会议上，小组可以解决其中25至50个缺陷。

测试主管在会议期间对美科利TestDirector进行信息更新，以便更有效地利用好会议时间。会议的中心议题是对缺陷报告进行审核。TestDirector中有完备的报告，包含所有的缺陷信息，便于会议划分缺陷的透明度、严重程度，并分配给相应的人员。缺陷报告的筛选可依据其严重程度和状态情况，这样影响度高的和新生成的缺陷可以最先得到处理。

状态显示为“New”的缺陷被首先审核，审核内容包括：

Ÿ          小结和描述：如果一个缺陷缺乏透明度方面的信息，使工作人员无法充分展开对其差异的调查，该缺陷将被退还到缺陷发布人员处进行信息补充。缺陷状态保持“New”。发布人员在美科利TestDirector中对该缺陷进行信息更新和补充之后，该缺陷通过测试主管被分配给项目经理，并将遵循状态为“New”的缺陷处理流程而展开。

Ÿ          严重程度：审核信息的精确性，并达成团队的共识。

Ÿ          任务指派：将缺陷指派给适合的小组（环境、开发或业务分析小组）展开调查并着手解决。注释:当分配情况发生变化时，美科利TestDirector将发送给受托人一封电子邮件，以告知变更情况。这是一项非常强大的工具，受托人可以立刻获知他们是否需要处理某个缺陷。

Ÿ          状态：状态从“New”变为“Open”。

缺陷被指派给某个工作人员之后，该受托人将会收到由美科利TestDirector发出的一封电子邮件，电子邮件还会在每次缺陷状态改变时，向测试主管发出通知。在一个新的缺陷被输入系统时，项目经理和测试主管也会收到电子邮件通知。每次当缺陷状态从“User Error”变为“Works”时，测试经理会收到电子邮件通知，接着测试经理就能利用这个信息进行监测。每次当状态变为“Reopen”时，开发经理会收到电子邮件通知。TestDirector可以很方便地进行客户定制，无需程序员就能实现变更。变更需要经常进行，从而为流程改进提供支持。一个测试人员只需要花费他50％的时间就能实现对TestDirector的管理，完成所有的尝试性和实际的变更，这就是为何要使用TestDirector这款工具的最具说服力的理由。

接着，小组将对所有状态为“Open”的缺陷进行审核，“Comments”的作用就在这个阶段显现。缺陷状态从“New”变化到“Closed”的整个解决过程中，缺陷所经历的各个阶段都有相应的评论被记录下来。“Comments”可以显示为什么要解决缺陷、如何解决的，以及何时得到了解决等各个方面的信息。恰当的任务指派可以使缺陷解决一起得到实现。

如果系统行为是令人满意的，无需进行修复（系统功能如期运作），缺陷信息就被更新成可接受，并分配给测试分析人员，他将把缺陷状态变为“Closed”。

小组还将审核在用户定义领域“Cause”中的输入信息，这就使小组能总结来自各个团队代表的建议，从而展开根源分析，并生成报告以备后用（用于流程改进）。对那些有争议的“Closed”缺陷可以选择该项审核环节。

缺陷修复

缺陷解决会议后，缺陷将被分配给合适的小组主管，以便着手解决。这些小组包括：开发小组、环境支持小组，或是业务团队。

1．如果该缺陷问题和需求有关，那么这个缺陷会被指派给业务团队。在这个阶段，根据需要进行需求变更。如果还需要代码变更，或者被认证用于下个应用发布改进的话，该缺陷将会被指派给开发小组。

2．如果对缺陷的代码错误有怀疑的话，该缺陷将被指派给开发主管。开发主管会指派给开发人员处理。当开发人员修复了代码，他会将缺陷状态变成“Fixed”。修复后的缺陷直接进入build打包中，并移交给测试小组。美科利TestDirector会生产一份报告，在一个build中显示所有被修复的缺陷。当该构成被移交给测试主管后，他们会将缺陷状态从“Fixed”改成“Ready to Retest”，并让测试人员进行缺陷的重复测试。注释：TestDirector能够为缺陷定义属性，以支持各类流程。其中包括“Code Fix”流程。当小组成员对TestDirector进行配置时，他们会考虑在修复流程中、开发人员优先权的制定中，以及修复时间的统计中，需要哪些属性来进行缺陷的跟踪。同样的过程适用于其它所有的团队。测试小组通过属性归属系统，对每个缺陷的信息质量实现控制。