Tracker的Transition Workflow 規劃與應用-以Bug 追蹤流程為案例

1.前言

CB自4.x版起開始支援Tracker Workflow功能, 例如Requirement, Change Request , Bug 或是Task 的生命週期的管理, 讓專案團隊的成員各司其職,更清楚每個議題(issue)發生時自己所必需扮演的角色與責任. 專案管理者可依據專案需求來設定Workflow, 不同的Tracker 可以擁有自己的Workflow . 如果需要將CodeBeamer的Workflow整合到公司內部已部署的Workflow, CB 4.0亦提供Web Service API 與 Server 的 Listener API 來與外部的Workflow/BPM系統做互動, 但此功能不在本文內探討. 本技術文件會以一個Bug的追蹤流程為案例, 此使用案例可能會與讀者公司內的Bug處理流程有所不同, 但讀者可藉由此案例說明以快速了解CB Workflow 的規劃與設定, 即可進一步設計出符合公司內部的Bug追蹤流程, 除了Bug追蹤流程, 讀者也可以自己設計工作指派流程, 變更管理流程.

2.CodeBeamer專案成員的設定

假設讀者已經安裝好CodeBeamer Trial Version, 並完成新增帳號與建立專案, 如果這部份有不清楚的地方請參考CodeBeamer User Guid 或是Demo Tour

專案角色規劃

以專案管理者角色登入Codebeamer, 點選要規劃Bug追蹤流程的專案,在做Workflow設定前, 我們先定義好專案角色與指定專案成員, 在本例中的專案角色與人員為

角色	負責事項	成員
Project Admin	專案管理	jeffery
品質管理經理	品質管理監控與稽核	tony
客戶/使用者	產品使用者或是Beta版使用者	andy
測試工程師	產品測試與測試報告	jhonny
研發工程師	系統開發與維護	george
技術經理	審核議題與負責指派任務給工程師	erik
程式碼品質管理主任	原始碼品質稽核	vincent

設計好的畫面如下

3.決定Bug的生命週期

由於目前CodeBeamer尚未支援圖形化的流程狀態設定, 筆者建議可以先用畫流程圖工具來規劃,在來設定CodeBeamer的Workflow,這樣對整個Bug的生命週期的輪廓會比較清楚. 在以下的流程圖中,筆者以三個不同形狀的區塊來代表流程圖中的

• Action: 使用者使用Action來達成Bug狀態的轉換
• Target Status: Bug 在每個生命週期的目標狀態
• Re-Assign: 重新指派負責專案成員

3.1先設定Bug每個生命週期的目標狀態

• Unset : 當使用者report一個Bug的初始狀態
• Accepted: 經過確認確實為Bug後,狀態更改為Accepted
• Resolved: 工程師將Bug修正, 狀態改為Resolved
• Verified: 測試工程師驗證修正後的版本, 狀態改為Verified
• Closed: 經過稽核Bug解決與測試過程記錄,再將這個Bug結束, 狀態改為Closed

3.2設計造成Bug狀態轉換的Action

設計Action的目的可以方便我們將這些Action轉換成CodeBeamer中的Transition Label

3.3設定CodeBeamer的Bug Tracker的Target Status

在流程圖設計,我們暫時先告一段落,我們還會再回到流程圖設定每個階段的負責專案成員, 我們先進行CodeBeamer Bug Tracker 的 Target Status 設定, 請以專案管理者bond帳號登入,點選 測試專案 , 點選Tracker如下圖

再點選 “customize” 進行Bug Tracker的客制化, 如下圖

再點選 “Choice Lists” TAB 如下圖所示

點選 “Status” 設定 Bug 的 Target Status value 如下圖所示

3.4設定CodeBeamer的Bug Tracker的 Status Transition

接下來就是要設定讓Bug的Status轉換的Action Lable , 這個設定對映到我們已經在步驟3.2的設計, 設定畫面如下圖

先將不在我們規劃中的Status Transition刪除, 選擇要刪除的Status transition再按 “Delete..” , 如下圖示, 為已經刪除後的畫面 再新增我們規劃的Status transition, 選擇 “New” 來新增一個Status transition 如下圖, Action Label的名稱也可以設成中文, 但為了和我們之前 設計的Action一致, 我們先用英文表示

依續以上步驟, 將我們規劃的Status Transition一個個加上去, 最後畫面如下圖所示

3.5設定Status Transition的執行權限

在設定Status Transition時想必讀者也注意到了每個Status Transition對應到Submitter, Assignee, 與專案中的每個Role都有一個Check box,這個Check box正是代表對應的Submitter, Assignee, 或是Role是否有權限來執行Status Transition. 如果我們只希望被Assignee擁有唯一的執行Status Transition權限, 可以設定如下圖所示 如果您希望讓專案經理也可以執行Close Status Transition 可以設定如下圖所示

3.6設定每個Target Status 的 Assign to 預設專案成員

Status Transition在CodeBeamer的設定大致上已經完成90% 那還有最後10%呢? 我們先回到我們先前所設計的Status Transition 流程圖 我們發現似乎少了什麼? “人”是專案開發最重要的元素, 怎麼沒看到每個狀態的負責人? 沒錯聰明的讀者應該想到應該為每個狀態設個預設負責專案成員,這樣當有新的Bug 至少會有預設專職負責review bug的專案成員來回應, 所以我們又為每個Target Status設定預定的責任專案成員如下圖

• 當New一個Bug時其Default Status為 “Unset” Assign to 為bond
• bond 檢視完Bug後按了 “Accept” action button , Status變為”Accepted”, Assign to 為 zsolt
• zsolt 解決了這個Bug然後按了 “Resolve” action button, Status變為 “Resolved”, Assign to 為 yuhui
• yuhui 下載新的版本並測試與驗證這個bug是否真的解決了, yuhui測試完發現bug確實已經解決了, 所以按了”Verify” action button, Status變為”Verified”, Assign to 為 bond
• bond 檢視bug每個status的歷史紀錄, 很滿意整個bug的解決與驗證流程, 所以按了”Close”, Status 變為”Closed”, 代表這個Bug已經完成

3.7設定執行Status Transition後的表單欄位修改/讀取權限與欄位初始值

接下來我們再回到CodeBeamer來完成最後每個Status階段的Assign to 預設值設定與欄位的修改/讀取權限, 在此必需要解釋一下為何要設定執行Status Transition後的表單欄位權限, 當專案成員執行Status Transition時 CodeBeamer 並不會馬上將Status直接轉換, 而是出現表單讓專案成員填寫, 例如 add comment 或是設定Bug被解決後的source code會在那個版本release, 這個在做Status轉換前的表單與權限是可以設定的, 因為並不是每個Status轉換時所需要填寫的表單是一樣的. 這個設定在Customization的”Field Access” TAB 如下圖所示

CB-4.x使用者請注意! 5.0版後,這邊的Workflow Status表單欄位也影響到當Status轉換後的表單編輯權限,CB-4.x版在每一個Status轉換後的表單權限都是跟Status == unset(or "--")一樣的,5.0版這個加強功能可以限制當Workflow到某個狀態,使用者只能限定修改特定的欄位. CB-4.x 5.0.x 5.2的使用者請注意, Transition的表單欄位權限功能有變更, 請參考CodeBeamer知識基礎/Tracker的Transition Workflow 規劃與應用-以Bug 追蹤流程為案例/CB-5.3版Transition Workflow功能變更說明

我們可以先設定每個Target Status的Assign to 的預設值再來做欄位的讀取/修改權限

在上圖中我們設定當使用者新增一個Bug, 其Target Status為Unset(系統預設值), Assigned to的預設值為jeffery, 如果新增bug的使用者角色為客戶/使用者, 對於Assigned to這個欄位只有Read權限, 如果新增Bug的使用者為其他角色,則有權限來修改Assigned to欄位的值, 當Bug已經新增完成, 在執行Accept Transition時Assign to的欄位值要預設為erik, 則必須到Workflow transition的編輯表單中設定, 如圖18所示, 在此只列舉Assigned to這個欄位的預設值設定所有專案角色對於這個欄位的Read/Write權限, 讀者可以視實際需求來設定其他欄位的設定 在此先列舉 Unset 與 Accepted 兩個Target Status的 Assigned to 的預設值設定,其餘Target Status設定以此類推, 每個Target Status設定完後要記得按Save已儲存設定

3.8測試設計好的的流程

• 先登出
• 用角色為客戶/使用者的andy登入, 到測試專案的Bug Tracker 新增一個Bug

• 按NEW新增一個Bug,請比對照圖17的設定, 與下圖設定的結果再確認是否預期的設計一致

• 登出andy帳號, 使用jeffery帳號登入, 並到測試專案的Bug Tracker

• 下圖為點選Bug後所顯示的詳細內容, 而且可以看到我們所設計的 “Accept” Action Lable , 當Status 為 Unset 時只能做 Accept 動作,在最後會有一個範例展示如何在Status為Unset時加上一個Not Accept 的 Action lable

• jeffery檢視完bug 按 “Accept” 表示接受, 並啟動Status Transition

如下圖所示其Assigned to的預設值為erik (請參考在3.6中的Assigned to預設值設定與圖18的Field Access設定,下圖中的UI Layout為Field Access設定的結果)

• jeffery寫完comment後按”Submit”, 則狀態會變為”Accepted” Assigned to 為erik
• 登出jeffery帳號使用erik帳號登入,並到測試專案的Bug Tracker, 如下圖所示

• 在上圖中, 點選History, 可以看到這個Bug issue表單欄位被修改的歷史紀錄接下來的測試可以由讀者自行練習, 以驗證流程是否如我們規劃(如圖15所示)進行

4.Re-Assign

在這個流程中zsolt的角色為研發部經理, zsolt可以將這個Bug Re-assign給工程師解決,所以zsolt必須有Re-Assign的權限, 我們修改了流程如下

4.1設定Assigned to欄位的修改權限

使用bond帳號登入,到測試專案的Bug Tracker Customization設定畫面, 點選 “Permission”設定Issue 操作權限如下圖所示

• Issue-Edit Any 表示對應的Role每一個Issue都有Edit權限
• Issue-Edit if Owner 表示Role為Issue的Submitted by 和 Assigned to 時才有 Edit 權限

4.2設定Assigned to欄位的Read/Write權限

CB-4.2.x 使用者這個地方要注意, CB-5.0以後版本,Tracker欄位的權限是依Target Status而定,所以設定欄位權限要選擇Workflow Status,本例中當Status == Accepted時要讓技術經理能編輯Assign to欄位,所以Worlflow Status要選Accepted

4.3確認是否可以Re-Assign issue給其他專案成員

使用erik帳號登入, 並到測試專案的Bug Tracker, 打開測試的bug如下圖所示

5.流程修改

在現實開發專案中, 並不是Bug概括全受, 有些Bug其實是規格定義的問題, 可是在我們這個範例流程中確沒有”Not Accept”的流程選項, 當Bug新增時只能Accept卻不能Not Accept, 與實際的工狀況不太相符, 所以我們再將流程修改如下 再重複3.3的設定, 新增Target Status , 設定Transitions, 新增一個Transition 為 “Unset” to “Not Accepted”, 並設定Target Status為”Not Accepted” 的Field Access設定 當新增一個Bug 後, bond看到的畫面如下圖所示

6.結語

為了讓專案管理者迅速學習如何設定CodeBeamer的Workflow所以列舉一個比較簡單的流程範例, 而且沒有將Source Code commit與 Source code Review , 的流程列入此範例,讀者可以參考”CodeBeamer+SubVersion實務手冊”裏面 有詳述SCMLoop, 讀者可將SCMLoop與CodeBeamer的Workflow結合, 在Bug的工作流程中就可以再加上一個Source code Review 的流程, 這樣可使Bug Workflow更趨嚴謹.