在測試工程師的世界裡，Defect 像是勳章、獎狀，是在無數個版本裡殺進殺出後取得的輝煌功績。而 Defect Tracking System 是展示區，各種大大小小的問題都被陳列在這裡，供團隊追溯與回憶。
但東西放久了會生灰塵，Defect 放久了則會出現 破窗效應，於是展示區成了高亮區，團隊成員開始踢皮球或是無視這些 Defect，如何管理好 Defect 成了個難題。
繼續閱讀 “庫存 Defect 對於團隊生產力是有害的"
標籤: bug
Hooray for Buggy Software
參考網址：Hooray for Buggy Software
這篇文章將軟體開發分為三個階段，每個階段有不同的測試跟著並行去做。所以在不同階段發現的 bug 數量有不同的意義。應該要針對不同階段去探討，而不是只是因為發現很多 Bug 而感到開心。
Defective Bug Reports
在說一些 bug report 的注意事項，裡面有些在微軟測試之道那本書裡有提過。裡面最嚴重的問題應該是「測試步驟不完整」，這會浪費很多時間在找尋 bug 如何發生。
一些改善 Bug Report 的方法
此文針對無法複製的 bug 做探討，以及給予一些改善 bug report 的方法。
其中作者特別提倡做探索性測試時遇到 Bug 要立即寫出錯誤報告，擅用偵錯工具，內容資訊越充足、有效越好。
雖然寫錯誤報告需要花費一點時間，但會節省很多後續釐清問題的時間。
繼續閱讀 “一些改善 Bug Report 的方法"
遇到無法重現的 bug 時，該怎麼辦？
參考網址：如何对待测试中不能重现的BUG
當我們遇到不可重現的 bug 時，首先要先努力的去還原環境，可能像是長時間的使用，或是多次的操作後才容易產生出問題。如果真的無法重現問題時，也不能忽略假裝沒看到，要先把問題盡可能詳細的記錄下來，下次再遇到時才可以透過紀錄來找尋可能的原因。
如何有效的紀錄 Bug
所以我們在告訴人家問題時，操作步驟是必要的，但是如果當對方還是無法重製出問題時，我們就必須把錯誤訊息的內容清楚的告訴對方，並且把每個敘述都要明確詳細的說明。
這篇文章作者提出他覺得哪些地方應該要被記錄。
不論是開發或是測試應該都要透過要做好 log , 這樣之後要找問題也比較快速方便。
參考網址:Optimal Logging
記錄太多冗長的資訊會造成記錄大量數據，而且較難找到所要的訊息。但記錄太少的資訊時會造成訊息不完整，很難知道詳細的問題到底是什麼，因此文章提出了一些作者認為應該要記錄的訊息還有一些不需要記錄的訊息。
科科和測試 