Bug 回報怎麼寫？重現步驟、欄位範本與填寫範例
「匯出有問題」這張單到了工程師手上，常常還要問三次。在哪一頁？選了什麼條件？是檔案沒下載，還是打開後沒有資料？把標題改成「報表套用本週篩選後，匯出的 CSV 只剩欄位名稱」，下一個接手的人就知道去哪裡查。
寫 Bug 回報時，先想像你明天休假。同事能不能從卡片準備資料、走完操作，並看出結果哪裡不對？要交接的是能重做的操作和能核對的結果，原因等查過再補。
先寫重現條件，再寫操作
從測試者看不見的地方開始。像是「進報表頁」之前，可能要有匯出權限，也可能要先有一筆落在日期區間內的資料。如果換成管理員帳號就測不到，帳號角色就是重現條件。這類資訊寫在步驟前，接手的人不必邊做邊猜。
| 回報欄位 | 怎麼寫才有用 |
|---|---|
| 標題 | 寫出功能、觸發條件與看得見的錯誤，例如「本週報表匯出只剩欄位名稱」。 |
| 環境、版本與前置條件 | 記下發現在哪個環境、當時的版本、必要角色與資料。只有特定裝置或瀏覽器才會發生時，再補型號和版本。 |
| 重現步驟 | 從別人能到達的起點出發，一步一個動作。需要觀察畫面或檔案時，直接寫明要看哪裡。 |
| 預期與實際結果 | 兩欄各寫一句。預期可引用已確認的需求或既有規格，實際結果用錯誤字樣、筆數或畫面描述。 |
| 頻率、影響與證據 | 寫實際測了幾次、哪些人或流程受影響。附件用測試資料，附能對上該次操作的時間或畫面。 |
Bug 回報範本
把這段貼進看板或表單。影響還不清楚就填「待確認」，並把已經查過的條件記下來。
標題｜［功能＋觸發條件＋錯誤現象］
發現環境／版本｜［測試或正式環境／版本或 Build］
前置條件｜［帳號角色、設定、資料］
重現步驟
1. ［起點與操作］
2. ［下一步與輸入］
3. ［查看哪裡］
預期結果｜［應該出現什麼，必要時附需求］
實際結果｜［看到什麼，附錯誤文字或筆數］
發生頻率｜［幾次成功重現／總次數］
影響／替代做法｜［哪些工作卡住，是否有暫時做法］
證據｜［已遮蔽的截圖、檔案或紀錄連結］
相關卡片｜［原需求或疑似重複的 Bug］填寫範例｜本週報表匯出的 CSV 沒有資料列
以下是虛構的報表工具案例。測試站 v1.4.2 有三筆落在本週的資料，測試帳號可看報表也可匯出。操作只做三步。
- 開啟報表頁，把日期篩選設成「本週」。
- 確認畫面有三筆測試資料，再點「匯出 CSV」。
- 用文字編輯器打開下載的檔案，查看欄位名稱下方有幾筆資料。
預期結果是 CSV 包含欄位名稱與畫面上的三筆資料。實際結果是只有欄位名稱。用同一組資料試了三次，三次都出現。清除日期篩選後可匯出有資料列的檔案，但檔案會包含其他日期，需要另外核對日期範圍才能使用。這個差異可以寫進卡片，讓工程師先從日期篩選和匯出的交集查起。
只出現一次、或看起來像同一個 Bug 時
遇到偶發問題，把首次發現的時間、時區和當時的操作寫下來，再記錄後來試過哪些條件。例如「同一瀏覽器、同一帳號，重跑五次只有一次失敗」。仍然有影響就先留單，讓後續找到同樣現象的人補證據。若截圖有客戶姓名或訂單號碼，先在測試環境用假資料重做；需要引用紀錄時，只留排查所需的資訊。
先搜一下相同功能和錯誤訊息。若已有一張卡的觸發條件相同，把新環境、版本和證據補上去。如果兩張單都叫「匯出失敗」，其中一張按下按鈕完全沒反應，另一張則能下載空檔，先分開記，查到同一原因再關聯。
嚴重度、優先度與修復後怎麼驗
嚴重度描述影響，例如「畫面仍能查，本週 CSV 無法使用」。優先度描述要先處理哪一件，例如交件就在明天，又沒有可靠替代來源，排程就可能要往前提。把時間壓力、受影響的流程和替代做法寫出來，排程的人比較有依據。
修復後，先用當初三個步驟跑一遍，看 CSV 能否匯出正確的三筆。若改動碰到共用的日期篩選，再抽一組跨週資料，核對匯出有沒有多帶或漏掉邊界日期。把重測版本、環境和結果留在原卡。若這張 Bug 是上線必驗項目，也把它連回發布紀錄。軟體上線驗收清單
在 LIVO 怎麼填
工作區啟用 QA 後，可以到 QA 看板選「回報 Bug」。先選專案和環境，填問題標題、重現步驟、預期結果與實際結果，有版本就補到「發現版本／Build」。需要交接時可指定修復負責人和 QA 負責人。實際欄位顯示和必填設定依工作區而定。查看 LIVO 的 QA 功能
延伸閱讀。Mozilla 的 Bug 回報指南也示範如何寫可重現的步驟，以及怎麼處理偶發問題。
