不要重復發明輪胎。對于一位新的 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 周期中所有收到通知的活動者都能通過電子郵件收到相關的細節的同時，最小限度的向那些已經被淹沒在要求他們詳審的電子郵件中的用戶發送通知。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
