那張被關掉的 bug ticket，讓我搞懂什麼叫做真正的 bug report

目錄 那張被標成 Cannot Reproduce 的 ticket 我當時的理解：把看到的事情寫下來就好 問題其實不在功能，在於我的描述方式 我現在怎麼寫 結尾 那張被標成 Cannot Reproduce 的 ticket 那是我做 QA 第三個月，正在測 我們的 App 的計時種樹功能。 我發現一個問題：完成一次 25 分鐘的專注計時後，結束畫面顯示「種植成功」，但回到森林主頁，那棵樹沒有出現。硬幣也沒有增加。我覺得這是個很明顯的 bug，馬上開了一張 ticket，寫了這樣： 標題： 計時結束後樹木未種植 描述： 完成計時後畫面顯示種植成功，但森林主頁沒有新樹，硬幣也沒有增加。 送出去，自信滿滿等開發處理。 兩天後 ticket 被標成 Cannot Reproduce ，後面還有一句備註：「請補充測試步驟與帳號狀態。」 我當時有點生氣，心想這麼明顯的 bug 你找不到？後來我去找了開發，跟他坐在一起重現，才知道這個 bug 只有在帳號「第一次種樹」的狀態下才會發生——已經有種植紀錄的帳號不會觸發。而且需要是透過 Google 或 Apple 登入的連結帳號，本地帳號沒有這個問題。 開發說：「你的描述裡這些條件都沒有，我用自己的帳號試了三次當然找不到。」 他說得對。 我當時的理解 我那時候的理解是：bug report 就是把你看到的異常寫下來，讓開發知道有問題。 所以我的 ticket 通常長這樣： 標題：哪裡壞了 描述：看到了什麼 我以為這樣就夠了。畢竟我知道怎麼重現，如果開發有問題可以來找我。 這個想法讓我之後花了很多時間在 Slack 上解釋 ticket，幫開發補步驟，甚至親自坐到他旁邊示範。效率極差，而且 sprint 到後半段人人都很忙，這種來來回回很容易讓 bug 被往後排或直接被忽略。 更糟糕的是，有幾次 bug 被「修了」，但修的不是我回報的那個問題，而是開發自己猜到的另一個可能性。後來 regression 的時候才發現原始問題還在。 問題在哪裡 後來有個資深 QA 看了我的幾張 ticket，直接跟我說：「你的 report 是寫給自己看的，不是寫給開發看的。」 這句話讓我想了很久。 一份 bug report 真正的目的不是「讓對方知道有 bug」，而是「讓對方能夠在沒有你的情況下重現這個 bug，然後修掉它」。 這兩件事差很多。 前者只需要描述結果，後者需要提供足夠的上下文讓另一個人可以獨立重現。而且那個「另一個人」可能是一週後才看到你 ticket 的開發，中間沒有你可以問。 我發現問題出在三個地方： 前置條件沒寫清楚。 帳號狀態、登入方式、已有的資料都是條件。很多 bug 只在特定狀態下觸發，你不說開發不會知道。我們的 App 的很多 bug 都跟帳號是否有種植紀錄、訂閱狀態、用哪種方式登入高度相關。 步驟寫得太模糊。 「完成計時後查看森林」這樣的描述，開發不知道你計時了幾分鐘、選了哪種樹、有沒有在計時中途切換 app。每一步都要精確到動作層級。 環境資訊缺失。 同一個 bug 在 iOS 和 Android 上行為可能不同，在不同帳號狀態下行為也不同。App 版本、裝置、OS 版本都可能影響重現結果，這些不是多餘的資訊，是重現的必要條件。 我現在怎麼寫 現在我的 bug report 結構固定是這樣： 1. 標題：行為 + 條件 不是「樹木未種植」，是「連結帳號首次種樹後，森林主頁無新樹且硬幣未增加（v6.2.1+，iOS）」。 標題要讓人一眼知道在哪裡、什麼情況、什麼問題。開發在看 ticket list 的時候，能從標題就大概判斷影響範圍，這很重要。 2. 前置條件 前置條件： 使用帳號：全新 Google 連結帳號（從未種過樹） 帳號狀態：無種植紀錄、無訂閱 計時設定：25 分鐘，選擇「橡樹」（免費樹種） App 版本：6.2.1 裝置：iPhone 15 Pro，iOS 17.3 環境：Staging 這段不用寫得漂亮，清單就好，但要完整。 3. 重現步驟 重現步驟： 1. 以 Google 帳號登入（確認帳號無種植紀錄） 2. 點擊首頁「開始種樹」 3. 選擇橡樹，設定計時 25 分鐘 4. 點擊「開始」，等待計時結束（或手動快轉） 5. 計時結束，點擊「種植」 6. 觀察結束畫面顯示「種植成功」 7. 返回森林主頁，查看是否有新樹 8. 查看帳號硬幣數量是否增加 每一步是一個動作，數字排列，不要合併步驟。 4. 實際結果 vs. 預期結果 實際結果： 結束畫面顯示「種植成功」，但返回森林後無新樹， 硬幣數量維持原本的 0 枚，未獲得本次計時應得的 25 枚。 預期結果： 森林主頁出現新種植的橡樹， 帳號硬幣從 0 枚增加至 25 枚。 這兩欄要分開寫，不要混在一起。很多人習慣只寫「實際結果」，但開發需要知道你預期什麼，才能判斷這是 bug 還是設計如此。 5. 附件 截圖或影片。不是裝飾，是證據。 截圖要包含顯示問題的那一刻，如果流程複雜，錄一段影片比截十張圖有用。檔案命名要有意義， screenshot 2024.png 沒有 forest empty after plant success.png 有用。 6. 嚴重程度（Severity） 這個很多人會跳過或者亂填，但它影響 bug 被處理的順序。 我的判斷基準是： Critical ：主流程完全壞掉，無法進行（計時功能無法啟動、App 閃退） High ：主流程可完成，但結果錯誤（種樹成功畫面出現，但樹沒有種進去） Medium ：非主流程異常，或有 workaround（重新整理後樹才出現） Low ：UI 問題、文案錯誤、不影響功能 上面那個首次種樹 bug 是 High，因為它讓新用戶在最重要的第一次體驗就看到「成功」但實際沒有成功，嚴重影響信任感，而且新帳號比例不低。 一份完整的 ticket 大概長這樣： [High] 連結帳號首次種樹後，森林無新樹且硬幣未增加（v6.2.1+，iOS） 前置條件 帳號：全新 Google 連結帳號（無種植紀錄、無訂閱） 計時：橡樹，25 分鐘 App：v6.2.1，iPhone 15 Pro，iOS 17.3 環境：Staging 重現步驟 1. Google 登入（確認帳號無種植紀錄） 2. 開始種樹，選擇橡樹，計時 25 分鐘 3. 計時結束，點擊「種植」 4. 觀察結束畫面，返回森林主頁 實際結果 結束畫面顯示「種植成功」，返回後無新樹，硬幣未增加（仍為 0） 預期結果 森林出現橡樹，硬幣增加 25 枚 備註 本地帳號（非連結帳號）無此問題 已有種植紀錄的連結帳號無此問題 附影片：forest first plant bug.mp4 有幾件事我現在很確定： Bug report 要寫給沒看過這個 bug 的人。 你在意的是「能讓對方重現」，不是「記錄我測到了什麼」。這個心態的差別，決定你會不會主動補前置條件和環境資訊。 步驟寫完要自己試跑一次。 很多時候寫完才發現少了一步，或者順序不對。你在寫的時候腦中有完整的流程，但讀的人沒有。 不要只附截圖，截圖要有標記。 圈出問題在哪裡，加箭頭，用紅框。開發看到一張全畫面截圖，還要自己找問題在哪，這是在浪費對方的時間。 嚴重程度不要全部填 Critical。 我見過有人每張 ticket 都填 Critical，後來開發完全忽略這個欄位。這個欄位是溝通工具，用壞了就沒有意義了。 結尾 寫出一份好的 bug report，不是為了讓自己看起來更專業，是為了讓問題被正確、快速地處理。 那張被標成 Cannot Reproduce 的 ticket，責任不在開發找不到，在我沒有給他足夠的資訊。這個認知讓我後來每次寫 ticket 之前都會多問自己一句：「如果是我第一次看這張 ticket，我能重現這個問題嗎？」 這個問題問了幾百次之後，現在大部分的 ticket 我不需要在 Slack 上補充說明。省下來的時間，兩邊都受益。 我還是會偶爾漏掉某個環境條件，或者步驟寫得不夠精確。這不是一次學完的事，是每次開 ticket 都需要有意識地去做的事。 如果你的 ticket 常常被要求補充資訊，或者被標成 Cannot Reproduce，值得回頭看看這些地方。