[心得] Bug的分級與解決

作者wt (Time to Change!)

看板Soft_Job

標題[心得] Bug的分級與解決

時間Thu Jun 2 20:37:30 2022

這邊介紹比較正式的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://www.ptt.cc/bbs/Soft_Job/M.1654173453.A.C23.html

→ brucetu: 其實很多軟體公司只有一句 "有使用者反應會閃退" 結束 06/02 20:43

→ brucetu: 使用者給一星寫說會閃退很爛你也沒辦法問到什麼 06/02 20:43

→ brucetu: UI沒對齊如果是老闆講的優先權會變第一 06/02 20:45

→ wt: 使用者反應會閃退，表示測試能量不足沒有抓出來。 06/02 20:53

→ wt: 是團隊該檢討，而不是檢討使用者。 User願意給回饋已經很好了 06/02 20:53

→ wt: 至於老闆說就變成第一優先，就是最後一段說的。 06/02 20:54

→ wt: 管理階層本來就會對Issue優先權進行調整 06/02 20:55

推 abccbaandy: 但這個權限正常是基於讓產品更好情況下使用 06/02 20:59

→ abccbaandy: 3F說的明顯不是 06/02 21:00

→ wt: 實務上，商譽跟(辦公室)政治因素也都會影響決策 06/02 21:08

→ wt: UI沒對齊可以解讀成對商譽的影響。如果會被當成軟體團隊程度 06/02 21:11

→ wt: 程度不好的UI issue至少都會是P2。 P3 大概是1px 沒對齊這種 06/02 21:11