在軟體測試方面, 辨識 bug 很重要, 但報告 bug 也同樣重要, 甚至更重要. Bug 報告是軟體開發的關鍵步驟, 它可以讓 工程師, 測試人員 和 管理者進行溝通, 解釋出了什麼問題, 為什麼會發生, 以及如何修復它. 不幸的是, 許多軟體測試人員沒有具備正確撰寫 bug 報告所需的技能.

1. 簡單易懂

Bug 報告要能看得懂, 聽起來很理所當然, 但是實務上不容易做到.

首先, 要能提供足夠的資訊. 有些時候沒有附上畫面截圖, 或者是沒有系統運作的 log 檔案等等, 導致開發人員還需要請你再送給他.

另外, 有些測試人員在寫 bug 的資訊時, 非常惜字如金, 太簡短太抽象, 導致他無法從 bug 報告上看懂, 需要請你再來解釋給他聽, 這樣不行. 需要讓所有的讀者, 或是相同專案團隊的人, 在你不在的狀況下, 就可以自行看懂.

圖 24-1 簡單易懂要做到的點

2. 要了解你的 觀眾

會閱讀 bug 報告的人, 不止只有一種角色, 他們有不同的需求, 你需要針對他們的需求, 寫出他們想要的資訊.

• 要解 bug 的工程師
工程師最重要的任務就是解bug, 解 bug 之前就是要能先重現 bug. 因此你需要說明如何才能重現, 不是只是跟他說有 bug.

另外要能解掉 bug, 一方面 debug information 需要有, 另一方面他也需要知道預期結果是什麼, 否則它可能認為這是對的結果, 或者是他解出的跟你要的不同.

如果可以的話, 測試人員提供大約哪邊錯誤的訊息會更好, 這樣開發人員會更愛你.

• 要檢視 bug 的經理
經理會檢視 bug 報告, 主要是要決定哪些 bug 要先處理, 因此測試人員比需要提供資訊讓經理可以做決策. 像是 bug 的嚴重程度, 會影響到哪些功能, 或是哪些系統.

經理需要調度開發人員去解重要的 bug. 因此也需要讓經理知道, 每個人身上有多少 bug, 嚴重程度如何. 此外還有哪些功能還沒測, 或者是哪些功能的災情很慘重. 這些都會影響經理如何調度人手.

• 要和客戶溝通的 support
support 除了要和開發團隊溝通外, 還要面對的是客戶. 客戶通常對專業知識是不懂的, 他們只聽得懂白話文, 高深的系統專業文是不了解的. 因此, 測試人員不能把開發人員對問題的解說, 直接丟給 support. 必須要適當地翻譯, 好讓 support 知道如何說給客戶聽.

3. 錯誤報告是 推銷 的工具

大家都知道, 如果我們只是說這個技術有多棒, 別人可能不會買單. 就像人工智慧一樣, 從下圍棋打敗棋王, 到 ChatGPT 出現, 大家已經對人工智慧的能力有深刻的印象, 但是大家還是在等待他的應用. 如何可以實際影響到人們的生活, 如何可以幫大家賺到大錢.

同理, 在 bug 報告上面也是如此, 你不能光是講這個 bug 是什麼. 這樣開發人員或是經理, 不見得會很重視, 畢竟他們身上還有很多更重要的事情要做, 像是開發新的功能, 或者是去釐清某個需求. 你需要從商業的角度, 從利害關係人在意的事情著手. 例如:

這個會導致主功能無法使用, 所以接下來無法繼續測試, 測試將會延遲一週或者是看開發人員什麼時候修好才能繼續.
這會使作業系統藍屏, 客戶的資料都會流失.

當然有些小 bug 確實不容易引起關注. 這時候你可能需要找尋以前外面客戶進來的 case, 來佐證以前發生過這樣的問題, 現在又發生, 這樣觀感不好.

或者你可以說, 這些是小的問題沒錯, 可是我在 10 分鐘內會遇到 5-6 次, 我覺得客戶很難忍受這個狀況. 就像小蚊子, 雖然傷害性不高, 但是一直在旁邊嗡嗡叫, 會令人精神崩潰.

事先預想好開發或是經理會找什麼理由, 然後你也準備好反擊的道理, 或者是客戶在意的事件.

4. 報告代表你 本人

你知道開發人員也是會挑測試人員的, 並不是要一個程式鼓勵師, 而是要一個能夠在工作上幫得上忙的. 而在 bug 方面要幫什麼忙呢? 就像前面說的, 要能說得清楚 bug 是什麼, 以及提供幫助解 bug 的資訊. 如果你兩項都能提供, 開發人員將會很樂意跟你合作.

正常狀況下, 開發人員還是從技術角度出發, 或許你不懂得寫出很棒的程式, 但是對於系統運作原理, 程式基本邏輯, 還是要能夠講得頭頭是道, 不會覺得你是在講一些亂編的話.

另外, 經理也會閱讀 bug 報告, 詳盡的分析和專業的建議將會幫你加分. 很多人會問我如何評價一個測試人員的績效好不好, 我會說看數字可能不一定準, 並且你可能還沒有收集那些數據. 因此. 我通常會建議看他所撰寫的 bug 報告. 有些測試人員寫的鉅細彌遺, 並且都會有重點摘要, 你不需要看完全部, 就知道接下來可以去做什麼. 對於他的細心和專業, 會整個讚不絕口.

所以 bug 報告就代表你本人. 認真的內容, 某種程度也表示你是個可靠的測試人員.

5. 努力讓錯誤報告更有價值

Bug 報告不該只是來紀錄 bug, 修復 bug 使用, 它還可以來做很多事情. 例如:

• 開發人員真的產生很多錯誤
我們可以用它來統計, 那些地方比較不擅長. 例如: 哪些模組比較多問題, 哪些人比較多 bug, bug 的類型都是哪一種, 發生在什麼階段等等, 都可以幫助開發人員更了解自己, 知道自己在哪邊可以再加強.

• 需求或設計規格不足或不正確
有些並不是寫程式的問題, 而是跟需求或是設計有關. 這些如果有識別出來, 可幫助日後要求PM 或是架構師要注意和改進

• 輔助建立內部/外部的已知問題清單
每個版本所找到的 bug, 可能不見得全部都會解決. 也就說會留下一些 known issues. 我們可以把他整理下來, 讓 support 或是需要對外的人, 馬上就可以查到哪些問題我們還沒解掉.

• 系統內部維修技術手冊來源
在 bug 報告內, 通常有很多解決問題的細節, 很多是很寶貴的經驗, 我們是可以把他們整理起來, 讓其他人或是團隊日後可以參考. 不旦有明確的步驟, 並且還有實際案例可以參考.

• 下個版本需求或是改進來源
就像前面提到, 找到的 bug 並沒有全部都解掉, 因此當要進到下一個版本時, 這裏的 bug 報告就是很好的參考來源, 可以在 kick off 之前檢視過一次, 挑出值得在一版處理的 bug 清單.

6. 小心修改 別人的內容

你會發現某些人寫的內容, 和你想的不同, 很容易會想要去修改它的內容. 但這會產生一些問題, 你如何確認你沒有誤解, 以及別人可能會認為你不尊重他.

因此, 我會建議你不是 update, 而是 append, 例如你在 bug 報告中, 可以增加註解, 並且加上姓名和日期. 例如:

[David 2014/3/8] xxxxxxx
…..

[Jessie 2014/4/12] xxxxxxx
….

[David 2014/3/8] xxxxxxx
…

[Joe 2014/3/8] xxxxxxx
…

7. 不要用錯誤追蹤系統決定績效

很多人會問 bug 數目, 是不是可以用來當作績效的參考. 這個確實很難說.

對於開發人員, 我遇到不少狀況, 就算他平均每行產生的bug 數和別人差不多, 因為他負責範圍比別人多, 會被抓到的 bug 數, 自然就是比別人多. 所以其實是他很辛苦, 多做了很多事情.

對於測試人員, 有時候因為你算 bug 數來當 KPI, 他可能會把同一個場景的錯誤, 因為不同段, 就切成不同個 bug 的紀錄. 或者不同地方發生, 但是相同原因, 他把這些都當作不同 bug 紀錄.

剛剛這些是不是分成不同 bug 紀錄, 是可以討論的. 但是都分成不一樣的 bug 紀錄, 在追蹤管理上有時候是滿辛苦的, 剛開始你不知道是有關連的, 所以你需要花時間去檢視確認, 最後才發現這些是同一個 bug 時, 心裡有時候是會覺得很累的.

所以我比較在意他們是否好好做事. bug 數是一個參考, 但是 bug 寫的內容的品質也是個參考, 不管內容是開發人員或是測試人員更新, 通常有心的話, 內容都會寫得不錯.

8. 何時 要產生錯誤報告

基本上這個答案是越快越好.

身為測試人員, 需要主動報告有錯誤發生. 不要拖到明天, 即使明天也可能會來不及.

因為你可能會延誤解問題的時機, 尤其是有些很困難解決的 bug, 一發現第一時間就要請開發人員來命案現場驗屍, 這樣才能幫助開發人員縮短解決 bug 的時間.

另外, 因為你延遲提交 bug, 可能會讓經理以為天下太平. 讓他不小心先跟長官或客戶說可以發佈, 等到他看到你才提交, 這時候他可能會很想死, 因為等等要花很多時間去跟利害關係人解釋, 避免他們會對我們有不信任感.

9. 分清楚 Priority 和 Severity

根據前面章節的定義:

• 優先順序 (Priority): 這個是從專案角度, 來思考這個 bug 的優先順序
• 嚴重性 (Severity): 這個是從測試人員角度, 來思考這個 bug 的嚴重性

為什麼會有這兩個看起來很像, 但是不知道何時會用到的東西哪?

在測試人員找到 bug時, 會設定 bug 的嚴重度(Severity), 但是這個值是從測試人員的角度思考, 也就是從專案或是從 bug 的本質思考.

可是在專案的進行中, 經理會根據外界需求, 決定哪些事情要先做, 因此要有個地方去設定這些狀態, Priority 就是最好的地方. 隨著專案的進行, 不同時間點會有不同的優先級. 例如: bug 被找到時可能是 P2, 因為目前還排不到要被修復, 就先保持 P2, 等到某一週需要修復它時, Priority 就可以調整成 P1, 讓開發人員知道他要先處理這個 bug.

那你說那就保留 priority 就好了, 幹嘛還要 severity 呢? 恩, 我們還是要尊重測試人員的專業 XDD.

當測試人員找到 bug 時, 可以根據其專業決定 severity 的內容. 接著搭配這個 bug是否一定發生, 來決定 priority 的內容.

10. 不能重現也要報告

老實說, 沒有不能重現的 bug, 只是看你對這個 bug的態度如何.

我曾經遇到很多很神奇的 bug, 一開始不知他到底是怎麼一回事. 但是, 就是那個但是, 它發生在客戶總經理機器, 或者是那個 bug 不解, 會損失好幾千萬以上, 你就會想盡各種方式來處理它.

那我們可以怎麼做呢?

至少可記錄發生的頻率和場景. 因為把這個關係記錄下來, 可以幫助你再想想是否可以還有其他可能.

那這些 bug 通常會怎麼發生呢? 以下是我常見的場景, 你可以從以下狀況去思考, 並且想辦法整理這些狀況, 以後可以幫助你找得更快.

• 第一次才發生
• 和特定的時間或是資料有關
• 在某些錯誤狀況下才發生
• 記憶體不夠
• 不正常的指標
• 需要和其他軟體共存才發生

11. 小心 措辭

測試某種程度有找砸的味道在. 開發人員因此而不滿是很正常的. 因此, 在 bug 報告上面不要有情緒性的字眼, 一切都是讓數字或是證據說話, 那樣會比較那樣會比較客觀, 有什麼事證就說到哪邊.

另外, 如果可以, 也盡量提供一些建議. 開發人員收到這麼 bug 心裡一定不好受, 他擔心的是要如何解. 所以你在 bug 報告上能多提供這些線索, 也會幫助緩和氣氛.

如果你寫的是英文的話, 可能也要注意英文的用詞和習俗, 至少都是大寫就不是那麼合適, 看起來在強調和罵人.

12. 撰寫錯誤報告的技巧

為了讓 bug 報告能容易了解, 以下是幾個經常使用的招式:

• 使用簡明的句子
• 為每一步驟編號
• 用最少的步驟來描述
• 加入適當的空白行以方便閱讀
• 要說明自己預期什麼
• 先說結論, 後寫細節
• 如果覺得很嚴重, 要說明為什麼嚴重
• 要用市場的數據, 來支持你的論點