要點
　　1.為什么你會遇上這些bug？因為它們是你放的。
　　2.在TDD（測試驅動的開發）中，你會在一個嚴格的反饋循環中，開發測試與生產代碼。
　　3.TDD可能有助于避免惱人的Zune bug。
　　4.目標硬件瓶頸有多種形式，你可以在嚴格的TDD反饋循環中，用TDD來避開瓶頸。
　　5.TDD幫助你確保自己的代碼如期望那樣運行。但如果不是這樣，你該如何建立一個可靠的系統？
　　6.TDD快速地發現小的和大的邏輯錯誤，防止出現bug，使最終得到較少的bug。
　　我們的工作方式都是編寫代碼，然后努力讓它運行起來。先建立，然后改錯。測試是以后的事，即寫完代碼后才要做的事。在不可預期的調試工作上，大概要花掉我們一半的時間。在日程表上，調試工作都穿著測試與集成的外衣。它是風險與不確定性的一個來源。修正了一個bug可能會產生另一個bug，有時甚至是一連串的bug。
　　保持調試的統計有助于預測要花多少時間才能消除bug。你要度量和管理bug。看曲線的拐點，拐點表示了趨勢，告訴你最后修正的bug要比產生的多。拐點表示的是已經做的事，但你永遠不知道是否在代碼的某個陰暗角落還躲藏著其它的致命bug。
　　可制造性設計的一個方面是確定為什么你會有這些bug。答案很簡單：錯誤是我們放進去的。這就是我們的工作方式。在開發以后的測試時，就會發現問題（圖1和參考文獻1）。我們在開發時會制造錯誤，測試的工作就是找到這些問題。只要仔細地測試，就會發現錯誤。開發后的測試工作意味著必須找到、修復和管理大量的錯誤。
　　
　　圖1，在開發以后做測試時，會發現缺陷
　　這種調試居后的編程程序是當今最常見的編程方式。先寫代碼，再調試它。調試居后的編程方式有風險。人都會犯錯誤。你既不能確定bug將在何時現身，也不能確定會花多長時間才能發現它們（圖2）。
　　
　　圖2，人都會犯錯誤。你無法確定bug何時出現，以及要花多少時間才能找到它們
　　當發現一個bug的時間（TD）增加時，尋找bug根源的時間（TFIND）也會增加，通常增加得更多。如果從錯誤的引入到發現要花數小時、數天、數周，甚至數月時間，你已忘掉了當時的背景，必須開始做bug大掃蕩。當你在開發周期以外發現缺陷時，就必須管理bug。對于有些bug，發現的時間不會影響修復的時間（TFIX），但有些代碼的運行也可能依賴于bug，修改這些bug會造成其它bug。
　　短周期以及主動的測試自動化可節省時間和工作量。這時，你再不需要重復繁重而易錯的手工測試。有了測試自動化，重復測試幾乎不會增加額外工作量。測試自動化快速地探測出副作用，避免了對調試事務的需求。