亂亂寫 Blog

我們知道團隊裡面有不同的角色來分工，同樣地在工作項目 (Work Item) 上也是需要分門別類地記錄不同性質的工作內容。

有人可能會反應現在專案從頭到尾都是我一個人搞定，為啥還要這麼麻煩呢？？所有的東西都在腦子裡啦！

但真的每個開發人員都這麼利害可以記住所有的東西嗎？？ ( 至少小弟沒有辦法，我連上個月寫的東西都不太記得了 @@ 憾顏呀！)

而且，沒有記錄下來對自已來說也實在是太沒有保障了，因為口說無憑嘛！

 

這個項目基本上應該會是由 Test 團隊來進行記錄

 

之前我們介紹了需求 ( User Story ) 的基本建立 ，而 PM 或 SA 談好需求後就可以再讓 PM 或 SD 來拆分細項工作 ( 類似 WBS )。所以透過 Implementation 來建立工作單 (Task)，同時亦可讓  QA 來分析此需求是要用什麼樣的「測試情節」來驗證此需求。 

Test Cases 的建立方式就和 Implementation 是一樣的。只不過 Link type 在這裡只能選擇「Tested By」  ( 這裡是透過 需求 來建立的 )

  ( User Story 的 )

 

Test Case 的畫面

在這裡預設的項目已經沒有「反覆路徑」了，這也是蠻合理的，因為 Test 的動作會一直重覆出現並都會跟著需求。

在步驟 (Steps)  新增了全新的 Control ，我們可以直接在這裡記錄測試的步驟和驗證的規則。  ( 本來我想要把 「邊界值」也加上去，但 CTP 這版會掛掉只好等之後的新版本嚕 )   ( 測試步驟群組化也是一樣 )  

當然在上面也可以設定 check point 以及關聯每一個步驟的附件

另一個比較特別的是，SSTab 最右邊有 Associated Automation ，裡面的  自動化測試的定義也是非常重要的，可以指定某一個已經建立好的 Test 。

不過，目前沒有建立好的 Automated test 所以無法選，這個待後續的時候再驗證。

 

從這裡就可以很清楚地知道，工具是如何幫助我們將「需求」和「測試計劃」結果在一起，並可以在未來的每一個階段反覆測試和監控進度、測試狀況之間的關係。這對團隊來說可是相當棒的

看一下報表很容易知道每一個需求的工作情況，以及那些是通過測試的 或是尚未執行測試的。

% Hours Completed 是代表工作的完成度，淺藍色代表未完成的。

Hours Remaining 代表這些未完成的工作還要幾個小時才能完成

Tests   代表該需求對應了幾個測試案例

Test Resultes  代表測試結果！！   深綠色 = 已通過測試   /     紅色 = 未通過測試  /    黑色 = 根本沒有執行測試  ( 最危險 )

 

有了這個後，以後我們家的測試就可以不用再自已去對應自已測試的項目是對應那一個功能 和 通過比例之類的了。 ( 計算這個很花時間的，以前都看她要快半天的時間 )    現成的報表就很棒啦！！