昨天成功上報一個 Bug，今天要來進行 Bug 生命週期的探討

成功上報一個 Bug 然後呢？

筆者發現上報一個 Bug 並不難，就是走個流程，其中值得注意 Bugzilla 設計的引導流程，先是讓你選擇 bug 的類型，然後再強制讓你針對 bug 下關鍵字來搜索現存的 bug！

於是這篇文章要來瞭解紀錄 bug 的生命週期，從 bug 出生到結束究竟該經歷哪些過程呢？我們先繼續來看第二章裡面有內容

目前還以有下章節沒瀏覽

• 2.3. Understanding a Bug
• 2.4. Editing a Bug
• 2.5. Finding Bugs
• 2.6. Reports and Charts
• 2.7. Pro Tips
• 2.8. User Preferences
• 2.9. Installed Extensions

簡單來說在 2.3 主要講解的是 bugzilla 在操作介面的使用，還有一些設計背後的用意，裡面著重在於 flag 的機制與說明，簡單來說 flag 主要的用途是顯示 bug 目前的狀態（底下節錄原文的範例）

A developer might want to ask their manager, "Should we fix this bug before we release version 2.0?" They might want to do this for a lot of bugs, so they decide to streamline the process. So:

1. The Bugzilla administrator creates a flag type called blocking2.0 for bugs in your product. It shows up on the Show Bug screen as the text blocking2.0 with a drop-down box next to it. The drop-down box contains four values: an empty space, ?, -, and +.
2. The developer sets the flag to ?.
3. The manager sees the blocking2.0 flag with a ? value.
4. If the manager thinks the feature should go into the product before version 2.0 can be released, they set the flag to +. Otherwise, they set it to -.
5. Now, every Bugzilla user who looks at the bug knows whether or not the bug needs to be fixed before release of version 2.0.

接著 2.4 章節則是著重說明編輯 bug 的細節，筆者注意到是 2.1 真的只是單純「提交 bug」，接著 2.2 - 2.3 則是提交完以後「bug 的詳細狀態編輯」，這個設計相當的有趣，這有點像是幫 bug 註冊一個身份後，才能開啟後續更多的功能，就好像會員制的系統～

那 2.4 說明了什麼？

1. 針對 bug 的身分證明（attachment）進行有效或是無效的投票（就像巴哈的 GP/BP 概念）
2. timetracking：bug 的 dealine 或是完成所費時間...等等與時間相關的屬性
3. Bug 的生命週期！！

沒錯，文件在 2.4 揭露了「Life Cycle of a Bug」，不囉唆！底下直接上圖(取自官網，版權)

Bug 的剛被註冊初始狀態會是 UNCONFIRMED，如同下圖紅框處

Bug 確實存在的情況
這代表此時 bug 是被一個非產品的內部人員註冊，並且需要被內部人員核實過後才會進入 CONFIRMED，這時如果 Bug 的狀態會取決於組織內部的開發安排（上文提到 Flag 的概念），進入到 IN_PORGRESS 的狀態，但若是因為計劃改遍就有可能導致狀態回到 CONFIRMED，並且在修復完後會暫時進到 RESOLVED，這時會轉交由 QA 來進行審核，如果不滿意就得退回 CONFIRMED 的狀態，如果滿意就會進到最終 VERIFIED，但是一切都有變數，有可能因為修復和 QA 都忽略了某種情況，導致其實並沒有修復成功就會回到 CONFIRMED 的狀態。

BUG 重複
如果被內部人員識別為「重複、無效、不會被修復」會直接從 UNCONFIRMED 到 RESOLVED，並透過 QA 審核進到 VERIFIED，然而如果最後被識別為可能的 Bug，也是有可能 REOPENED 回到 UNCONFIRMED 的狀態。

結語

如果從開發專案的角度來看，這一套 Bug 的生命週期每個步驟都有相對應的角色要做決策，可以從中學習 Bug 管理的方法，透過這樣有效的方式來管理 Bug 相當的好。

若是從開源組織的角度來看，我們可以藉此了解到 Bug 的生命週期，每一個步驟都需要「人的貢獻」，使用者能夠替 Bug 註冊身份，然後開發者能夠進行開發與 QA，人人都有機會參與，並且都有紀錄！