Cody Blog

如何寫 Bug Report

一個好的 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

img

Testing

Related Posts

Comments