前言

開發人員與測試人員齊心協力，相愛相殺， 榮辱與共，方能打造出優秀的產品。
若是bug描述不知所云，bug修復倉促隨意，bug管理如同兒戲，則金玉其外已是造化，敗絮其中當屬必然。

bug描述

好的描述能降低溝通成本，讓人審題時如沐春風，解題時酣暢淋漓。bug描述的主體，應該包含如下部分：

標題：指明所測模組，簡明扼要地描述問題現象
[前提條件] 說明完成測試的預設條件是什麼
[重現步驟] 句子簡練，步驟清晰，表達無歧義
[實際結果] 按照步驟執行下來，實際結果是什麼；不要有主觀色彩
[期望結果] 正確的結果應該是什麼；應該有說服力，不要唯經驗論

Tips:
其他如所測版本，附件資訊，bug優先順序等，不一而足，也是bug描述的一部分。

bug修復

望聞問切，才能直達病灶。解決問題是手段，預防問題再現才是目的。bug修復應該包含如下部分：

[根本原因] 造成這個bug的實際原因是什麼；不能諱疾忌醫
[解決方案] 通過何種方式修復；不要語焉不詳，不要選擇性發言誤導測試人員
[更改檔案] 此次修改更改了哪些檔案，以便程式碼後期維護，歷史追溯
[程式碼審查] 向檢查者描述問題和解決方案，這種二次檢查機制，不為事後追責，只為找出思維盲點，排除潛在風險
[影響範圍] 描述此次修改影響的功能範圍，便於測試人員驗證時覆蓋到更多的測試點

Tips:
根本原因、解決方案、影響範圍，是bug修復的3個核心要素。
明晰這3點，才能切中肯綮，收放有度，提高程式碼質量，避免regression。

bug的生命週期

一個bug的典型生命週期有這樣幾種樣態：

建立-> 調查 -> 確認 -> 排期 -> 修復 -> 驗證 -> 關閉
建立-> 調查 -> Not a Bug
重開，再次輪迴...

bug管理系統

常見的bug管理系統有：禪道、JIRA、Bugzilla等。
也可按需自行研發一套管理系統，系統無好壞之分，適合自己的才是最好的。

結語

好的產品應該是能解決使用者需求的，好的程式碼應該是可維護的。
當一個產品走過三五年、十來年，乃至更長，當碼農換了一茬又一茬，在軟體產品的生命中，過往的bug看似雪泥鴻爪，微不足道。
可當你小心翼翼的維護程式碼，當你搜尋bug管理系統，查閱程式碼版本庫時，卻發現前人的思路清晰可辨，那些bug還殘留著當初的溫度。