一個好的 Bug Report 應該要提供明確的資訊，可以讓 Developer 快速重視問題，減少分析問題的成本。而管理階層的人從報告可了解問題的嚴重性，進而決定解決這個Bug時間表。

Bug Report 應該要有的欄位

1. 標題
   說明要明確，直指問題核心，說明問題發生的模組

不好的標題: 照片無法上傳
比較好的標題: 當照片尺寸大於10MB，手機無法使用自動上傳照片

1. 問題重現步驟(Steps to reproduce)
   除了要找出可以重視問題的Steps之外，還要盡量縮小(narrow down)步驟，找出重現問題的關鍵步驟。通常最後一步會寫"預期的結果"(expected result)，實際發生的結果有什麼不同。

   1. 安裝 APP
   2. 使用 Google 帳號登入
   3. 點選登入按鈕
      預期結果: 登入成功，進入活動列表
      實際結果: 登入失敗，出現伺服器連接錯誤

2. 嚴重性
   Blocker: 產生無法使用，要立即解決，像是產品無法安裝
   Criticl: 嚴重的問題，需要儘早解決
   Major: 重要的問題，需要在產品上線前解決
   Minor: 次要的問題，不一定要解決，有列入已知問題(kownn Issue)的空間
   Trival: 不直接影響使用者使用，像是打錯字，等等

3. 問題發生的版本號

4. 發生的頻率
   每次/常常/偶爾/很少

5. 附件: 錯誤畫面的截圖，相關Log檔案以及任何可以幫助分析問題的檔案

一些原則

1. 如果測試一次發現多個問題，不要把多個 bug 寫在同一筆issue裡，分開一筆一筆記錄，這樣才可以獨立被解決跟驗證(Verify)
2. 確認這個 bug 是否已經記錄過了？ 不要重覆發。

Bug Workflow

這是一張在網路上找到一個比較簡單的 bug workflow