也順便寫了bug回報流程，但run了後才重新思考，什麼樣的bug需要tracking，什麼樣的data才有分析意義?
架系統不是重點，重點是，什麼才是有效的Bug Report呢?
Joel 給了我們很好的建議：
寫一份優良錯誤報告的規則很好記.
每個好的錯誤報告都要有剛好三個東西.
1. 重現的步驟,
2. 期望看到的, 以及
3. 實際所看到的.
另外，他也指出了錯誤追蹤的十大建議：
1. 好的測試員一定會試著把重現步驟減到最少步; 這對必須追出問題的程式人員來說極為有用.
2. 要記住只有一開始開啟的人才能關閉該錯誤. 其他人可以解決 問題, 不過只要最初看到錯誤的人可以真正確認所看到的錯誤已被修正.
3. 要解決錯誤有很多種方法. 常見的解決方法有fixed(已修正), won't fix(不予修正), postponed(暫緩), not repro(無法重現), duplicate(重複的問題), or by design(設計限制).
4. Not Repro表示沒有人能重現該錯誤. 程式人員在錯誤報告漏寫重現步驟時常常會用這一項.
5. 你需要小心追蹤程式版本. 每次發給測試員的軟體都應該有個編譯ID編號, 這樣可憐的測試員才不必在根本尚未修正的版本上測試同一個問題.
6. 如果你是個程式員, 而且想盡辦法都無法讓測試員使用問題資料庫, 只要不接受用其他方法寫的錯誤報告就可以了.如果測試員習慣用電子郵件送錯誤報告給你, 你就把信退回去並加上以下簡短訊息:"請把它放進問題資料庫中. 我沒法子追蹤電子郵件."
7. 如果你是個測試員, 而且想盡辦法都無法讓程式人員使用問題資料庫, 只要停止向他們報告錯誤 就好了 - 把錯誤直接放在資料庫裡並讓資料庫發信通知.
8. 如果你是個程式員, 而且只有部份同事在用問題資料庫, 只要開始在資料庫裡把錯誤分派給他們. 最後他們自然會明白的.
9. 如果你是個經理, 而且似乎沒人在用你花大筆費用安裝的問題資料庫, 那就開始利用它把新功能分派給大家. 因為問題資料庫也是個很好的"未完成功能"資料庫.
10. 要避開在問題資料庫裡增加新欄位的誘惑. 每個月總會有人想出個要在資料庫裡新增欄位的好點子. 什麼聰明的點子都有, 比如追蹤發現問題的檔案; 追蹤有多少比例的問題是可重現的; 追蹤某錯誤發生的次數; 追蹤某問題發生時機器上某個DLL的版本. 不要屈服在這些點子之下, 這一點非常重要. 如果你屈服了, 輸入新錯誤的畫面最後會出現上千個欄位要輸入, 結果是沒有人會想輸入錯誤報告. 要讓問題資料庫有效運作, 一定得讓大家都用, 如果"正式"輸入錯誤太麻煩, 大家就會繞過錯誤資料庫.
如果你非常欣賞獨孤木的文章(甚至跟我一樣，買了他的"在公牛身上擠奶")，或是蔡學墉的"Java夜未眠"，那你就更應該去瞧瞧Joel的文章。
Joel 的網站
中文翻譯：周思博趣談軟體
0 意見:
張貼留言