先講結論
修bug還要看影響程度 impact/severity
閃退是很嚴重的問題。 相當於app crash
除非你有權力決定/並扛結果，否則就是看上層要不要修。
或者能說服上層不修
閃退就算是1% 也算嚴重。
==> 不能假設只有1%的人會遇到，而是假設使用者用100次就會遇到的話，
幾乎所有使用者用久一點都有機會遇到
實務上，如果只有出現一兩次，而且經過特定時間的追查(例如幾天)
經過討論同意，有可能把case放入觀察名單暫不處理。把時間拿去處理其他事情。
也有遇過後期修bug，發現一次把前面幾個懷疑的bug close，
因為問題出現時的表現形態不同，導致之前開了幾個不同的bug tracking。
舉例：當進入某個狀態時，A、B、C各自會有不同狀況的錯誤，而開了3個bug。
題外話，機率是個模糊的定義。
Bug觸發機率不明，是因為沒有找到原因。機制找到就是100%
舉例：
某個bug只要符合ABC三個條件 100%發生。
但是平均每100個人，只有一人會操作到發生此問題。
請問此時機率該是 100% 或者 1% ?
這時判斷的重點反而是impact。
※ 引述《freebug (Freebug)》之銘言：
: 最近開發一個通訊軟體
: 有個閃退的bug自從上週被發現到之後就再也沒被觀察到
: 也就是這個bug的出現沒有規律性，只能靠碰運氣
: 出現機率也不高 (出現機率不到10%)
: 這也是我對這個bug感到煩惱的地方
: 如果各位遇到這樣性質的bug
: 你會怎麼去處理?
: 會去盡可能的鑽研，並且製造出這bug出現的可能嗎
: 還是會選擇直接忽略?