軟件工程界一直存在這樣的看法，“程序員不應該測試他們自己的代碼”，原因是程序員在代碼開發中形成的思維定勢將不可避免的導致測試的盲區，同時，就個人感情而言，個人很難否決自己努力完成的工作成果。
這樣的觀念使得專業的測試團隊的出現成為可能，于是，在現代軟件開發中，專業測試團隊的介入使得軟件的質量得到了相當程度上的保障。測試成為對軟件質量保證的最后哨卡，開始隨著人們對軟件質量和可靠性的關注而取得了日漸重要的位置。
但是，軟件工程的研究同樣告訴我們另外一個觀點：在軟件開發周期的越早期發現錯誤，那個錯誤將帶來的損失將越小。 下面這些圖表摘自<<實用軟件度量>>(capers jones，mcgraw-hill 1991)，它列出了準備測試，執行測試，和修改缺陷所花費的時間(以一個功能點為基準)，這些數據顯示單元測試的成本效率大約是集成測試的兩倍 系統測試的三倍。
盡管在傳統測試理論中，測試幾乎已經伴隨了整個開發周期：單元測試、集成測試、系統測試、驗收測試。但是，更多的時候我們遇到的情況是：至少在項目開始集成之前，測試是基本不存在的。程序員不愿意在模塊完成之后再花時間來寫測試代碼(事實上，很多程序員連文檔都欠奉)，而測試人員則不會寫測試代碼(能寫代碼的話通常都已經被抓去寫代碼了)。事實上，即使測試人員愿意寫測試代碼來完成對代碼的單元測試，這樣的分工也是不劃算的，因為這引入了額外的人與人之間的交流成本。于是我們的測試通常是在集成階段開始進入的，于是我們不得不在這個時候在來面對可能的模塊質量問題、模塊設計問題以及其他許多早在那之前就應該已經解決的問題。
這個情況在傳統工業里是不可想象的。你無法想象波音飛機在開始總裝之前沒有對它的零件進行過像樣的測試，但是你卻常�？吹轿覀儗σ淮蠖褯]有進行過單元測試的代碼進行集成。這個模塊有內部邏輯錯誤嗎?它有內存泄漏嗎?它能夠應付那些極端的邊界條件嗎?它達到了需求的要求了嗎?不知道，先拼起來再說，到時候測試發現不了問題就會放我們過關的。然后你盯著每周的bug 列表看，看到bug 數漸漸下降，漸漸的接近出廠要求，然后你擦擦頭上的冷汗：“感謝上帝，看來這次又過關了”。但是，難免會有一天，你的郵箱里塞滿了來自用戶的抱怨，告訴你你的程序又在某個你想不到的地方出了問題。
問題在哪?問題在于我們要求程序員在完成開發之后再完成一套東西的開發，而這些東西并不是要開發的軟件的一部分，并且將在項目結束時被拋棄。對程序員而言，這等于叫他額外的多完成一些原本不需要的任務，這是很難被接受的，即使他能理解這樣做的重要性。這是人性的弱點。那么，我們如何讓測試更進一步的深入開發過程，盡可能保證軟件每個組件的質量呢?這就要求我們放手讓測試驅動開發的過程，讓對需求的承諾直接的傳遞到每個組件的開發當中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
