這邊介紹比較正式的Bug處理方式。 一、Bug 分級：何時該修，何時可以不修 二、相關配套 補充：每間公司的文化不同，常見叫法有 Issue / Case / Defect(偏硬體廠商) ======================= 一、Bug分級 不是所有Bug都一樣嚴重，所以發現問題時，需要進行分級，來決定解決的優先順序。 類似醫院急診會需要先分級，有生命危險的優先處理，而不是先來先服務 (First come, first served) 當發現問題後，會需要回報以下資訊 。問題主旨 。問題描述 。優先處理性 Priority 。嚴重性 Severity / 影響 Impact 。頻率 Frequency 。相關資訊 - 發生版本 。重現步驟 Reproduce step 。相關Debug資訊 - Log - Screenshot/照片 ========== 。嚴重性 Severity / 影響 Impact 問題發生會造成的影響，包括 對產品造成的影響、對商譽造成的影響 通常會分4或5級 Critical (1)、Major(2)、Minor(3)、Improvement(4)、Suggestion(5) 簡單概念是 Critical： 造成產品/服務無法使用 ex: Crash/閃退，無法正常啟動使用 / 主要功能無法運作，影響後續測試進行(blocker) Major: 主要功能無法使用 ex: 某功能/function 操作結果與預期不同 Minor: 功能無法使用/不如預期，但使用者可以自己找到解決方法，或不影響操作 ex: UI 沒有對齊 Improvement： 既有功能可以更好，有空就做。 ex: 不到feature等級的改動。 or 決定這版本不修，放到下個版本處理 Suggestion： Nice to have 很少用到，甚至會跟improvement混在一起 ========== 。頻率 Frequency 問題發生的頻率、多久發生一次。通常無法量化表示，會用抽象的形容詞 比較常見的狀況是 Always(100%)、Often(>50%)、Sometimes(<50%)、Rarely(只發生一次) 上面的頻率只是抓個感覺，不必計較明確的百分比 例如在reproduce過程中 發現問題後，可以直接做出來 => Always 發現問題後，再嘗試了1次、沒有，第二次嘗試才做出來 => Often (2/3) 發現問題後，經過多次嘗試可以做出一次 => Sometimes (2/N) 只發生一次，不知道或者找不到明確觸發原因 => Rarely (1/N) =========== 。優先處理性 Priority 實際上決定bug要不要修，以及修的優先順續關鍵。 一般而言，都是直接按照 Priority做排序，由高到低來修 通常也是分4級 Priotiry 1~4 (P1~P4) P1：當天優先處理 P2：特定milestone前一定要修完/close P3：release前一定要修完/close P4：可修可不修 / 下個版本再修 如何決定Priority？ 由 嚴重性Severity x 頻率Frequency 決定 下表提供參考。實際上還是要看每間公司/組織自己定義 嚴重性 頻率 Critical Major Minor Improvement Always P1 P2 P3 P4 Often P1 P2 P3 P4 Sometimes P1 P2 P3 P4 Rarely P2 P3 P4 P4 例如： 程式crash/閃退，即使頻率很低，但影響很大，一定處理到底 (Critical x Sometimes => P1) UI沒對齊，很醜，100%會遇到但是不影響使用者操作，就會是 (Minor x Always => P3) ========== 二、相關配套 1. 通常會有一套issue tracking system來輔助。 如果還是用Email/Excel做紀錄的團隊，表示還有很多進步的空間， 可能也不會遇到上面的概念。 通常系統除了完整記錄資訊外，還有一些特殊功能 不同版本之間的串聯，這個bug發生後，回過頭可以去找到哪些版本/branch有一樣問題 可以把fixing直接導過去 (平行版本、客製版、不同語言版) 或者回頭去修上一版 (傳統on premise軟體、韌體) 掌握整個軟體品質狀況 (Manager/Leader level) 透過issue抓到的數量，導成S curve後，可以分辨出軟體中bug大約找出的數量與狀況 來判斷測試週期是否足夠，可否結束。 例如：在同樣的測試能量下，單位時間內被找的Bug數量是呈現往上還是收斂的趨勢 2. Issue Review 每天會Review當天找到的bug，針對Priority進行調整。 (Priority一開始是由發現者填寫) 除了調整順序外，會讓整個團隊清楚目前品質狀況。 參與者通常是Manager/Leader (Dev、QA、PM 至少各一) 先這樣，歡迎其他版友補充。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.169.208.120 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1654173453.A.C23.html ※ 編輯: wt (118.169.208.120 臺灣), 06/04/2022 00:34:49