協作式的Test Case Management

不管開發軟體或硬體, 我們都希望產品到客戶的手中能得到滿意的評價. 所以產品在出貨前確定客戶在所有可能的使用情境下,都能順順利利, 才逅得著"滿意"的邊. 這一方面仰賴設計者本身的品質修養,如寫code的邏輯和布局, 硬體零件材料如何選擇的經驗值,...., 另一方面Test Cases的coverage是否能夠包含所有使用的實際狀況,將決定每次release的品質. 也許一兩位好的QC人員有辦法寫出70% 的Test Cases, 避免嚴重的bugs. 不過, 有很多瑕疵有可能與當初設計的想法有關, 讓設計者與接近客戶的行銷業務人員或客服人員參與Test Case的討論, 將有助於讓Test Cases更接近客戶實際使用狀況. 也可以更貼近客戶的角度來認知Test Cases的輕重緩急, 或發掘更好的測試技術或方法. Test Case的執行, 相信也不是一兩人可以完成的.

在拜訪多家公司, 發現很多公司對於Test Case的管理很重視. 我們也看到大多數的管理的方法是運用Excel來做Test Case列表, 並確認是否每個Test Case都通過測試了. 這樣的作法應該是可行的, 不過我們多少聽到客戶不滿意的聲音, 畢竟Excel不能同時多人進去更新, 且不好寫很多細節, 更無法就每個test case做測試的細節把關. Test相關的文件或source codes, 要在Excel中標明, 還得寫一大串http或儲存檔位址的詳細敘述. 這些都造成Test Case Management所需要的協同作業滯礙難行.


是否可以運用協同作業的工具來克服這樣的問題呢?

運用Tracker來做Test Case List的討論應該是最有利於同時多人依每個人的專長自由發揮. 有的人會想到哪些使用情境需要測試,有的人對於測試的方法很在行, 有些人很清楚如何把關確認測試是否確實執行,有的人擁有測試的自動化的技術, 所以可能一個Test Case就有許多專家的貢獻,
當這些Test Case集中討論, 成為Test Case的知識庫, 對於往後同類型產品的測試與出版, 將可以省去許多不必要重製Test Case的時間, 且累積這方面的功力.

另一方面我們要注意的是, Test Case List應該隨需求變更和新發現的Bug做變動, 所以也應隨每次release的基線(Baseline)做定版留存. 定版後的Test Case當然要在每次release前確實追蹤, 確定所有的Test Item都通過測試後, 才可以出版, 否則, 就必須確實將Bug解決, 再重新release.

以下的video將展示可以如何運用協同作業的平台來做Test Case Management.
這裡主要運用可彈性客製化的Trackers,和文件管理整合起來的系統, 讓Test Case List的Discussion, 和測試執行可以如平行運算那樣有效率的進行, 且很容易回溯.
當然, 這樣也將有助Release的品質提昇.