最全面的 Bug 生命週期管理

Bug 生命週期管理算是很基礎的知識了，本來是沒什麼值得再提的，但是我從業了三家公司，所用的管理系統中，我感覺都沒有完美反映最全面的 Bug 生命週期，每一個系統都或多或少地缺少一部分。因此，在這裡想探討一下我理想中的最全面的 Bug 生命週期管理過程。當然，有很多我還沒有使用過的系統，可能它們已經很全面了。另外，可能還有遺漏的部分，歡迎大家一起探討。

先上圖：

根據上圖，整個處理流程如下：

1. 發現人發現 Bug 之後，在系統中錄入 Bug 單，還未儲存的時候，這個時候 Bug 就處於新建狀態。如果指定了修復人並儲存，那麼 Bug 狀態就變成了待修復。如果沒有指定修復人儲存，那麼 Bug 狀態就變成了計劃。當然，計劃狀態和新建狀態也可以合併。這個時候，如果指定了修復人並儲存，那麼 Bug 狀態同樣會變成了待修復。如果沒有指定修復人儲存，那麼 Bug 狀態就變成了新建。本帖採用的是前一種方式。

2. 當 Bug 處於計劃狀態，可以指派修復人，然後就變成了待修復狀態。如果是撤回或者打回之後變成計劃狀態，有兩種情況：

   a. 確認之後直接關閉 Bug。
   b. 不認可打回，可以重新指派。
   c. 撤回之後，修改相關內容後重新指派。

3. 當 Bug 處於待修復狀態，就有比較多的情況了：

   a. 如果發現人發現自己提錯了或者描述有錯，可以撤回，狀態變成計劃。
   b. 如果修復人覺得不是 Bug，可以打回，狀態變成計劃。
   c. 如果修復人覺得是需求，可以先轉交給產品經理，這個時候狀態還是待修復。產品經理評估後確認是需求，則可以轉成需求。狀態變成已轉需求，如果產品經理覺得不是需求，是 Bug，也可以轉回給原來的修復人。當然，如果產品經理覺得不是 Bug，也可以直接打回，狀態變成計劃。
   d. 修復人可以 Bug 狀態改成修復中，表示自己正在修復。處在修復中狀態的 Bug，除了可以重新變成待修復狀態之外，可流轉的狀態跟待修復狀態的 Bug 相同。
   e. 修復人可以在修復 Bug 之後，可以標修復完成。
   f. 如果修復人覺得 Bug 無法處理或者沒必要處理，則可以標成不處理。
   g. 如果修復人覺得影響不大，沒時間處理，可以標成下版處理。

4. 當 Bug 處於修復完成狀態，發現人如果驗證 OK，可以標成關閉。如果驗證不透過，則打回給修復人，狀態變成待修復。

5. 當 Bug 分別處在下版處理和不處理狀態時，可以分別標成確認下版處理和確認不處理或者打回。值得注意的是，這一步最好是由充當專案經理的角色來標。

6. 當 Bug 分別處在確認下版處理和確認不處理狀態時，處理人應該是發現人，這樣可以形成閉環，避免發現人丟失對 Bug 的跟蹤。這個時候，修復人可以選擇重新開啟或者關閉Bug。當重新開啟時，Bug 狀態變成待修復。多數情況下，確認下版處理的 Bug 預計下版是要重新開啟的，重新開啟後，Bug 的賬齡需要重新重置。而確認不處理的 Bug 除非發現人不認同需要重新開啟，否則可以直接關閉。

7. 關閉狀態和已轉需求狀態是最終狀態，當 Bug 處於這兩個狀態時，就無法修改了，也沒有處理人。

8. 每一次標狀態，都是可以寫備註的。建議除了指派、重新開啟、待修復變成修復中、確認不處理/確認下版處理變成關閉之外，其他情況都是需要備註原因的。

9. 為了保持靈活性，除了最終狀態，其他狀態要有 “轉交” 功能，可以轉交處理人。

10. 狀態轉換時，部分情況下處理人是不固定的，需要手動指定處理人。系統可以配置每次狀態轉換之後的預設處理人。一般以下情況需要配置：

    a. 修復中打回或者待修復撤回/打回之後，處理人都是發現人。
    b. 待修復和修復中之間轉換，處理人不變。
    c. 修復完成/不處理/下版處理打回、確認不處理/確認下版處理之後重新開啟，處理人都是待修復時的處理人。
    d. 待修復/修復中變成修復完成，處理人是發現人。

11. 每一個狀態轉換，多數情況下只有處理人才能改狀態。但是也可以配置許可權。比如待修復狀態，專案經理也可以標不處理，計劃狀態，專案經理也可以指派修復人等等。許可權項就不展開講了。

12. 偶現或者無法重現問題可以備註後標成不處理。專案經理確認不處理後，無法重現問題需要發現人持續觀察一個月，定期抽查驗證，確定無法重現後才能關閉。偶現問題需要發現人觀察一週，定期抽查驗證，確定無法重現後關閉。

13. 重複 Bug 可以直接打回。