雖然可能引起很多開發人員的爭辯，但是事實上很多開發人員不愿意花很多時間去先寫測試，然后開發代碼來證明測試通過了。
神話8："單元測試就是設計規格說明書"
無論你采用哪一種開發模式，在開發代碼之前你都必須對需求進行思考。雖然TDD的單元測試產物可以讓我們理解相當一部分的設計規格說明，但是仍然存在差距。
定義測試用例用于檢查需求并不是新鮮事。不管你采用的是什么開發模式，最重要的是針對每一項需求提出這樣的問題"我將如何測試它？"，這樣你的測試用例是在落實到代碼之前就被充分考慮過的，而不是等待將來的"重構"。
神話9："TDD適用于任何項目"
隨著項目規模的擴大，執行測試所需要的時間也在增加。這可以通過劃分項目和測試范圍來解決。但是無論如何都會導致測試運行的頻率不一致，這樣就需要測試的計劃和測試執行的管理，因此，除了白盒測試，我們還需要考慮以下幾種測試：
集成測試 - "我需要運行哪些測試來確保新的代碼與其關聯的代碼有效地工作在一起？"
系統測試 - "新的代碼在系統層面的功能是夠正確，與其他系統工作在一起的流程是否正確?"
回歸測試 - "我需要隔多久運行一次回歸測試來確保新的代碼沒有造成非預期的影響？"自動化的回歸測試為敏捷開發提供了一張安全網。
用戶驗收測試 - "TDD不僅需要確保某項功能正確地工作了，還要確保它們對于業務用戶來說是可接受的。"
然而，隨著項目組的擴大，測試的"自我文檔化"（self-documenting）不再可接受，因為參與的項目組成員越多，不同的人對需求的不同理解，項目的風險隨之增加。
隨著項目規模增加，需要開發的測試代碼也大大增加，測試代碼的維護工作量也大大增加，對測試自動化的需求也在增加，需要更多的自動化測試用于縮短每個測試周期的時間。
神話10："開發人員和測試人員是水火不相容的"
長久以來，開發和測試之間存在"你我之分"的緊張局面。這其實會是一種"共生共贏"的健康關系，如果能很好地一起正確地工作的話，這種關系可以為顧客產生更高的產品交付質量。
討論的焦點應該集中在：
- 交付的軟件需要滿足業務目標（滿足需求、按時、控制成本），而不是討論誰擁有哪一部分流程的權責問題。
- 測試人員在需求收集階段可以做出什么貢獻？如何讓他們更好地融入到TDD的過程中。
- 測試人員如何最大化地重用開發過程中產生的各項"資產"？
- 在TDD中是否有一個"傳統測試人員"的角色？或者他們是否需要像開發人員一樣掌握新的技術來適應新的開發模式？
- 在新的開發和測試工具中，開發人員和測試人員如何互相找到自己需要的東西？
結論
敏捷項目其實是QA領導敏捷過程的一個絕佳機會；誰是用戶和開發者之間的最佳橋梁，能理解各方面的需要，如何達成以及如何在開發之前就得到保證？
QA除了繼續在確保整個系統的演進滿足業務目標和需求外，應該對"如何"和"結果"兩方面都投入自己的興趣。但是這同時對QA提出了新的要求，他們必須自己"敏捷"起來，拋棄舊的模式，專注于應用新的技術來優化測試的策略。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
