这边介绍比较正式的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 至少各一)
先这样，欢迎其他版友补充。