每個軟體專案在開發時, 無論計劃多麼精心, 開發時如何詳盡設計, 在過程中都必然會遇到錯誤. 如何有效管理這些bug, 將決定專案的成敗. 有效的bug管理不僅可以確保bug得到及時解決, 而且對於維持團隊士氣, 和使用者滿意度也起著至關重要的作用.

首先, 我們要看得是 Bug 處理的流程. 下圖 23-1 是一個基本的流程, 很多 bug 工具一開始就給你這樣的流程.

圖 23-1 基本的 bug 處理流程

• New
在這個狀態, 當有人找到 bug時, 會提交一個新的 bug. 這邊不會指定是哪個角色, 開發, 測試, 客戶, 管理者都有可能.

• Active
當有 bug 被登記後, 並且確定這個 bug 要被處理, 就會進入到這個狀態. 這時候通常會指派一個開發人員去處理.

如果開發人員現在無法處理, 或者是需要再從新指派開發人員修復, 可以從 Active 轉換到 New 狀態.

• Resolved
當這個 bug 已被修復, 便會進入到這個狀態. 通常是由開發人員轉交給測試人員去驗證.

如果沒有修復成功, 測試人員會將 bug 退回給開發人員, 就會從 Resolved 狀態轉回 Active 狀態.

• Closed
這個 bug 已被驗證無誤, 測試人員便會將狀態轉換到 closed 狀態.

上面的流程大多適用於內部系統開發, 但是對於已經發佈的產品, 如果你有個 support 的角色, 那 bug 處理流程便會有所不同. 下圖 23-2 便是其中一種處理方式.

圖 23-2 產品發佈後的 bug 處理流程

在這個流程中, 客戶的問題會先進入到 support 手中. Support 會幫客戶提交 bug, 然後再指派給開發人員去處理. 當開發人員處理完後, 測試人員接著驗證. 以前產品開發到這邊就結束, 但是在產品發佈後, 測試人員做完後, support 會再確認一次, 並且還會到客戶環境去確認, 直到客戶說沒問題, 才會將這個 bug 關閉.

由此可知, support 是一道防火牆, 隔離客戶和開發團隊. 因為開發團隊或許有別的專案或是下一版要開發, 很多跟客戶的互動, 來來回回的糾纏, 都是由 support 幫你吸收. 為了能知道目前在 support 或是開發團隊的處理狀態, bug 流程需要把他們切分出來, 這樣管理者比較好一目瞭然.

在某些場景下, 你還想知道更詳細的狀態呈現, 這時候可以把 bug 處理流程再細化. 下圖 23-3 便是其中一種演進.

圖 23-3 更詳細的 bug 處理流程

有時候 bug 被提交, 不代表你就一定能處理, 因為你無法重現他的錯誤狀況, 有些時候是因為你缺乏資訊, 或者客戶講錯重現步驟, 或者是少給什麼資訊.

也有可能客戶都給了, 但是你沒有頭緒根本原因在哪, 因此你可以會多寫一些產生de bug information 的機制, 要求客戶幫你執行和收集, 這時候就要等待客戶回覆.

根據以上種種狀況, 我們增加了一個狀態: NeedInfo, 當你需要客戶幫忙, 不管是提供更多 debug information, 幫忙執行什麼, 或者多說一點重現資訊, 都可以把 bug 移動此狀態. 這樣你就可以區分, 這個 bug 是正在修復, 還是需要客戶幫忙.

另外, 當你要關閉一個 bug 時, 它可能不是因為被修復, 所以關閉的. 他有可能有其他的理由. 那你要怎麼知道呢? 這時候可以在 close 狀態時, 要求填寫填寫關閉的處理狀況. 例如:

• duplicate
這個 bug 重複了. 通常需要紀錄跟哪一個 bug 重複.

• cannot fix
這個 bug 無法修掉. 但是你會好奇為什麼可以關掉呢? 有可能是政治力搓掉的.

• can fix
這個 bug 是有修掉的

• user error
有可能是客戶或是測試人員操作錯誤, 系統其實是沒有問題的. 便可以算這項. 但是有時候增加一個新的 bug, 說這項功能用戶體驗不好, 導致他們常常使用錯誤.

所以, 你可以知道, bug 的處理流程不是固定的, 如果你需要知道更多資訊, 或者區分更多狀態, 你就會去調整 bug 處理流程.

接下來, 我們將要看 bug 報告中, 會需要紀錄哪些內容:

1. 報告標題(Title)

這邊簡單的說, 就是用一句話描述這個 bug 是什麼, 需要準確和明確表達問題的內容.

很多人會忽略標題, 但是我必須說, 當你的 bug 有上百個或是上千個時, 這個標題就很重要. 因為管理者或是收到 bug 報告的人, 他不見得有耐心去望下看報告的細節, 它可能需要從這個標題中, 就可以知道是否要先處理, 或者就先放在一旁. 所以好的測試人員, 需要在這個描述中下功夫, 讓別人一看到就可以下決策.

2. 報告描述 (Description)

這邊會進一步闡述問題的細節, 通常會寫比較長的說明, 會花一到兩段以上的文章, 來解釋到底發生了什麼事情.

3. 產品資訊

這邊的資訊, 將會提供開發人員修復的提示. 尤其是你給錯 build number 可能會導致開發人員無法修復, 或者是修復錯.

有些神奇的 bug 是和硬體有關, 或者和周邊系統有關的, 所以這種資訊就很重要. 有的公司會提供工具, 讓你預設就把所有相關軟硬體資訊, 在一開始就全部收集, 也避免遺漏.

• Version number
• Build number
• 硬體資訊: CPU, RAM, Hard Disk, NIC
• 作業系統資訊: OS, 資料庫, 瀏覽

4. 產生步驟 (Reproduce Steps)

這邊撰寫的就是如何重現的步驟. 這邊最好不要長篇大論, 而是應該要以條列式的方式來敘述. 並且要加上編號, 因為當之後有人看不懂時, 他便可以利用編號, 很容易來跟其他人討論. 否則就很難說明, 大家在討論的是哪一段.

5. 預期正確行為 (Expected Result)

聽起來很簡單, 就是描述測試的預期結果是什麼.

很多人說這個需要寫嗎? 不就是明擺的事情嗎? 我想你應該知道需求很容易誤解吧? 開發人員想的, 和 PM 往往不同, 很容易雙方解釋的不同.

同理, bug 會出現的一種狀況, 就是上述狀況的落實. 雙方對某件事上有不同的認知. 因此, 測試人員需要把預期結果寫出來. 否則開發人員會覺得這不就是這個系統的”特色”嗎? 這個系統本來就是要這樣動的, 到底錯在哪裡呢?

6. 優先順序 (Priority)

這個是從專案角度, 來思考這個 bug 的優先順序

7. 嚴重性 (Severity)

這個是從測試人員角度, 來思考這個 bug 的嚴重性

8. 發生頻率

說明這個 bug 發生的頻率如何, 是否總是發生, 或者是多久才一次.

對於總是發生的 bug, 這個資訊可能就不太重要. 但是對於不是總是發生的 bug, 這個資訊可以提供一些線索. 例如一天發生 1-2 次, 和 30 分鐘內會發生 1-2 次, 你覺得哪個嚴重呢?

9. 畫面截圖

很多時候有附上螢幕的截圖, 對於了解 bug 有很大的幫助, 可以讓開發人員很快知道問題出現在哪裡. 對於要管理 bug 的經理們, 也能很快分辨這個 bug 是否重要.

10. Log files

這裡是指 bug 重現過程中, 產品所產生的紀錄檔案. 裡面會有產執行相關的資訊, 或是產生的相關資料.

很多開發人員會說沒有這個他們不會修復 bug, 或許是誇大之詞. 但是也說明這個東西的重要性.

11. 如何發現

這邊是指用什麼方式找到這個 bug. 像是測試自動化, 探索式測試, Scripted testing, 客戶回報 等等. 收集這個資訊可以讓我們了解, 哪些方法找到 bug 比較有效率. 或者可以知道我們大多進行哪些作法.

12. 發現的階段

這邊是指在什麼時間點, 什麼階段找到這個bug. 例如: 開發, Alpha, Internal Beta, External Beta等等, 這裡是根據你的開發流程來列出相對應的階段. 我們會觀察是否能夠比較早期就找到問題, 還是我們大多集中在測試中後期才找到問題. 這也是觀察測試流程機制的效率如何.

13. 所屬模組

這邊是在說這個 bug 是發生在哪一個模組上面. 這是開發人員要填寫的欄位. 並且是在修復後才填寫的, 這時候才會是真的答案.

14. 如何處理

這個欄位是指如何處理這個 bug. 也就是上面 bug 處理流程中, closed 欄位描述的事情. 這也是開發人員要填的, 通常會有以下狀況:

• 需修改
• 不需修改
• 無法重現
• 重複的 bug
• 設計的問題

15. 錯誤原因

這裏會希望開發人員要詳細描述 bug 形成的原因, 這個資訊可以幫助測試人員, 讓他們知道哪些需要加強測試. 對於管理者也很重要, 可以利用這些資訊來決定日後要怎麼改善.

• 需求規格錯誤
• 例外處理錯誤
• 輸入資料錯誤
• 架構設計錯誤
• 安裝/部署
• 其他

16. 修改的檔案

這裏是指修復 bug 時, 會動到哪些檔案. 一方面讓開發人員整理自己做了哪些修改. 另一方面, 也讓測試人員檢查, 開發人員說的和真實改動的檔案是否一致. 還是有偷渡了什麼東西進來.