我提議從一個缺陷開始，反過來倒推出一個有效的流程。下面是我所認爲的具體做法
第一步：收集我們發佈給用戶的所有缺陷（特別注意安全漏洞）。不要象對待會跳出來咬傷我們的蛇那樣對待它們，相反，把他們認爲是公司的一種資產。這樣，它們就明確地指出我們是否有流程問題，思路是否有方向性錯誤，或是否犯了錯誤。如果不能從自己做錯的事情中吸取教訓，應該感到慚愧。如果我們拒絕承認自己做錯了，那麼問題就更嚴重了。
第二步：分析每一個缺陷，這樣我們就可以做到三點：（1）停止類似的缺陷；（2）更擅長尋找類似的缺陷；（3）明白在類似缺陷發生時，如何識別它們。
第三步：在我們的團隊中培養這樣一種文化，每一個開發人員/測試人員或者技術人員都理解我們曾寫過的每一個缺陷。
第四步：將學到的內容整理成文檔。這是編制有關已知缺陷的系統知識的基礎部分，它也是創建新的方法集的基礎，這些方法可以預防我們再犯那些最糟糕的錯誤。
我們通過指認自己寫過的缺陷來完成上述工作。我認爲下列三個問題是一個很好的開始。
1.一開始是什麼錯誤導致了這個缺陷？
2.出現什麼樣的失效症狀時，能警示我們現在存在這個缺陷？
3.哪些測試技術能找到這個缺陷？
對於我們在測試中完全忽視的缺陷，需要理解哪些測試可以發現這種失效，並幫助我們診斷出這種故障。這樣一來，便又在測試系統知識中加入真正能有效找到重要缺陷的測試。
其結果是更高效的測試和更短的測試周期。
二
測試錯誤代碼
開發人員寫兩種代碼。第一，完成工作的代碼，我們稱這種代碼爲功能代碼，因爲它提供了滿足用戶需求的功能。第二，還有一種代碼用於保護功能不會因爲錯誤的輸入（或者其他一些無法預計的環境條件）而失效。我們稱這種代碼爲錯誤處理代碼，因爲它能處理錯誤。對於很多程序員來說，這種代碼是他們被迫寫的，而不是必要的，編寫的過程也不是很讓人愉悅。
測試錯誤處理代碼需要考慮很多因素。最重要的是理解應用程序如何迴應錯誤的輸入。我試圖區分三種不同的錯誤處理程序。