[心得] Bug的分級與解決

這邊介紹比較正式的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 (臺灣) ※ 編輯: wt (118.169.208.120 臺灣), 06/04/2022 00:34:49