不要重复发明轮胎。对于一位新的 ClearQuest 管理员来说，Rational ClearQuest 论坛是最值得访问的站点，它的网址是：IBM developerWorks。该论坛提供了寻找用户贡献的 hook 例子的去处，并且可以寻找您在配置过程中所遇到的问题的答案。
除了讨论，在 ClearQuest hooks index 里还有许多 hook 执行的例子。如果您试图添加一个 Choicelist、添加 auditing functions、或者使用 ClearQuest 来加强特定域的约束或者验证，那么这里有许多例子可以帮助您完成您的个性化定制。
在 ClearQuest hooks index 中浓缩了数百小时的开发时间。应用别人的经验来加强您的执行将是一个不错的选择。
  |
|
ClearQuest 和 Crystal Reports 之间的关系有时将会使该工具的初始配置变得混淆，对于新人来说尤其如此。最简单的解释就是，在其当前形式下，每一个客户端的所有用户都能够运行报告。该报告是报告格式和定义需求的结合体。然而，问题在于细节，并不是每一个客户端都能够制作 Report Formats。
只有用于 Windows 的 ClearQuest 客户端，并且在其系统中加载了 Crystal Reports 的支持版本，才能够创建出生成报告所需要的 Report Formats。由于 Crystal Reports 是一个单独的应用程序（需要额外的许可证费用和额外的产品安装），所以经常有人向管理员出售 Crystal Reports 许可证，并且为 Report Formats 建立一个“票据交换所”。
这种事情您应该避免。只需不到 600 美元，您就能购买到 Crystal Reports 的一个副本。对于机构来说，一个更有利的情景就是“培训和培训者”模型。ClearQuest 管理员培训不同项目团队中的核心成员，这些成员购买 Crystal Reports 并且在其系统上装载了 ClearQuest Windows 客户端。这样一来，ClearQuest 管理员将有能力使得团队使用任何满足其需要的方式，利用储存在 ClearQuest 中的数据来生成报告。
|
|
这或许听起来像是一个技术之外、无关痛痒的话题然而，这正是许多新的 ClearQuest 设计者经常掉进的一个陷阱。
当使用 ClearQuest Designer 的时候，选择一个操作，经验欠缺的开发者往往会添加一个用户群到操作中。假定该操作是 Approve。您或许创建了一个名为 Java_Project_Approvers 的用户组，并向其中添加了三位管理者。然后您将那个 Java_Project_Approvers 用户组连接到 Group Permission，在图表中核查，并且更新数据库。
一周以后，C# 项目发送了一封电子邮件，要求他们的管理团队获得 Approve 操作同样地约束。于是您必须重复所有的步骤；即连接 C#_Project_Approvers 用户组到 Group Permission，在图表中核查，并且更新数据库。
更好的方法是创建一个名为 Approvers 的“顶级”用户组。。然后，根据需要添加单独的、特定项目的用户群，作为与该操作相关联的子用户群。
在我们的例子中，我们创建一个名为 Approvers 的“顶级”用户群，它有两个子群，分别叫做 Java_Project_Approvers 和 C#_Project_Approvers。然后，当 C++ 用户群在第二周时再次申请时，您就能够不用再进行在图表中核查、添加用户群和更新图表的工作了。Group Permissions 的管理现在仅仅是一个用户和用户群的管理功能了。
通过连接被称作 Approvers 的高级别用户群的约束，向约束中添加额外的用户或者用户群仅仅需要您在用户管理工具中修改 Approvers 用户群的成员，而不是修改图表和更新数据库（请见图2）。这一过程帮助我们避免了频繁地更新图表和数据库所产生的大量的推理。
图 2: 通过同高级别的群体联合行动，您能够将“团队特定的”子群体添加到行动中，而且不需要对计划做出改变
|
|
由于 ClearQuest 的强大功能和简单易用，经验并不丰富的设计者频繁的试图过度改造 ClearQuest 的电子邮件规则功能性。我曾经遇到过一个超过 100 条电子邮件规则记录的配置，其中 90% 都是基于查询的。这样做不仅产生了大量的电子邮件，而且会动态的影响任何操作的执行。
由于基于查询的电子邮件规则都是基于主要的 Defect 记录的，每一次进行操作，这 90 多条规则就将决定该查询条件是否曾经被满足过。无疑，客户端将会非常疑惑为什么在点击 Apply 按钮后需要等待这么长时间才能得到 ClearQuest 的回应，完成修改记录的操作。
对于新近配置 ClearQuest 的机构，我的建议是制定在 ClearQuest 以及 State 和 Action 工作流中将要跟踪的角色，并且决定在过程中需要布告的重要阶段何时发生。经验欠缺的 ClearQuest 用户试图在每一次状态变更时发送提交布告。Submitter 域在提交时期被填满，将 Submitter 参考域添加到 CC 中非常简单：让电子邮件规则排队。
|
| |||||||||||||||
然而，容易完成并不意味着就应该完成。想一想个体所提交的缺陷将收到多少非 ClearQuest 的电子邮件规则。使用一个基本的 Defect 工作流，他们就有可能收到 6 至 7 封基于状态变更的电子邮件。将您自己置身于提交者的位置，您应该能够就能够快速的将布告降至两至三个动作。
对于提交者来说，最明显的布告就是提交动作。这将影响到检验他们的缺陷已经进入到系统中，为他们提供一个系统为该缺陷指派的 ID，并让他们有机会回顾一下他们所提交的细节，开发团队将会使用它来分析该缺陷。一旦缺陷被提交，您可以选择再一次通知提交者（仅仅是提交者）通过或者终止该缺陷。这样的话，当该缺陷被成功解决之后，提交者将被告知他们的请求正在被处理（或者被拒绝，或者标记为副本，等等）。
基于这些“里程碑”状态变更的电子邮件通知将为提交者提供价值。持续不变的电子邮件通知，比如缺陷被开发人员指派或者打开、或者记录被升级，将会被提交者当作“背景噪声”，甚至是垃圾邮件。
应当仔细的思考和计划，从而确保在整个 Defect 周期中所有收到通知的活动者都能通过电子邮件收到相关的细节的同时，最小限度的向那些已经被淹没在要求他们详审的电子邮件中的用户发送通知。
文章来源于领测软件测试网 https://www.ltesting.net/
