3． "開發人員可以用開源工具寫測試，因此我們不需要測試人員或者自動測試工具了"
職業測試人員實現的是與其開發同僚不同但同樣有效的作用。
人們普遍認識到傳統的自動測試工具并不像供應商們炒作的那么有效。原始軟件的源碼和供應商的產品一樣可以改善數據庫測試環境下的效率。這是因為沒有合適的工具可以提供用戶界面測試，所以我們才把方案擴展到了這一領域；我們的傳統是有效地實施測試而不是屏幕抓取自動測試。我們開發了測試驅動，是因為在過去的二十年里傳統的供應商錯過了這個機會。
通常，TDD項目的測試代碼至少與應用代碼一樣多，因此其本身就是應用軟件。這種測試代碼是需要在目標應用的生命周期中進行維護的。
4． "有了單元測試就不需要手動測試了"
手動測試是一項重復性很強的工作；成本昂貴、枯燥并且容易出錯。雖然TDD可以減少功能測試所需的手動勞動，但是它不能消除對黑盒測試（手動和自動）的需求。
通過自動抓取測試人員的過程并記錄其鍵盤和鼠標動作，測試人員能夠騰出更多的時間來進行更有意義、更有價值的活動，比如測試難以（甚至無法）自動化的復雜場景。雖然手動測試很費時間（因此也很昂貴），但是如果因為不進行手動測試而漏掉一些錯誤，則通常意味著將來可能要付出更大的代價。
5． "我們不再需要用戶驗收測試"
在敏捷開發中，用戶驗收測試的定位通常是和用戶協作確定"錯誤的需求"，而不是檢查功能是否與需求匹配。用戶在最開始定義需求的時候，他們是根據自己的期望值來描述的。當他們看到"活生生"的系統的時候，他們必然還會產生一些不同的、或者額外的需求。雖然敏捷方法可以減少這種事情的發生概率，但是要完全解決這種問題還是不可能的，因此我們無法回避用戶驗收測試。商業用戶的用戶界面驗證就更無法回避了，因為他們想象的可能與開發人員稍有不同。而這就得由我們來……
文章來源于領測軟件測試網 http://www.kjueaiud.com/
