6． "自動化是不可能的"
在敏捷項目早期實現自動化通常很困難，但是隨著系統的發展和成長，某些方面已經確定，這時就該進行自動化部署了--通過自我修復腳本等處理改動。
開始的時候，用戶與QA的所有測試幾乎都是手動的，但是如果能夠抓取并重用這些測試活動和設計，這對以后的工作了是有益的。
自動化的時機很難掌握，因此一定要使用能夠先支持手動測試而后可以將其發展為自動測試的工具。
7. "開發人員都有足夠的測試技能"
前提是測試簡單到所有人都可以做，并且每次提交的代碼都是完美的�？上�，許多企業都只在開發人員的編碼技術和為他們提供最新的集成開發工具上投資，而忽視了發展他們QA團隊的測試技能，或者沒有為他們提供與開發人員同樣有效的工具。
一個獨立的測試團隊就像一個客觀的第三方，可以清楚地看清"全局"，能夠驗證可交付產品的功能與質量。雖然開發人員會盡力提供所需的系統功能，但是一個優秀的測試人員還是要客觀地提出"萬一……"之類的問題。如果你還考慮到了商業用戶測試，那你就更有可能完成一個符合要求的系統。
最后，雖然下面的觀點可能引起爭議，我還是要說大多開發人員實際上并不想花大量的時間先寫測試再寫代碼來驗證測試。如果以下描述的協作過程，開發人員可以獲得足夠的功能測試方面的幫助，從而集中精力編寫精準、穩定的代碼。
8． "單元測試就是設計說明書的全部"
不管用什么開發方法，在編寫代碼之前都要想清楚需求。雖然TDD說"做得不錯"可以代表設計說明中的很大一部分已經完成，我們仍然需要考慮單元測試中的一些空白。還有其它同樣可行的方案。TDD要驗證需求采集的準確性，而他們的依據并沒有得到歷史的證明。
用定義測試用例的方法來驗證需求的準確性與簡潔性已不是什么新概念。比如V模型，就是一種了解測試需求的有效方法--通常指功能性需求。就像TDD一樣，如果業者比較嚴格，而開發過程比較靈活，那么V模型以及其它模型就沒有辦法了。軟件工程并不像機械工程，強制順應只會浪費精力。不管你選擇了哪種方法，都要問每個用戶需求："我怎么來測試這個？"關鍵是要在代碼構建前檢查測試用例,否則你會花費更多的時間進行代碼重構.
通過協作對需求進行精簡以后，開發人員就可以拿到一份比較穩定的說明文檔，這份文檔可能會較少地發生變動，因為它已經經過了多方面的評定。
9． "TDD適應于任何項目"
隨著項目規模的增大，進行測試的時間也越來越長。這個問題可以用對項目和/或測試進行劃塊的方法解決。無論哪種方法都會產生要根據其與當前代碼的相關度運行的測試。這導致了對測試計劃和執行管理需求。為了獲得較高的效率，除了白盒測試，你還需要考慮：
集成測試——"我需要哪些測試來保證新代碼與其它代碼能夠無縫合作？"
系統測試——"新代碼支持的功能與系統或其它系統的功能結合密切嗎？"
回歸測試——"為了保證新代碼不會產生不可預料的反作用，我需要以多大的頻率運行回歸測試？"自動回歸測試可以有效地驗證敏捷開發技術。
用戶驗收測試——"雖然TDD（與業務用戶協作）可以保證某個特定的功能能夠正常工作，但是經過各種各樣的變動之后，累積的影響還能被用戶接受嗎？"
然而，在今天的環境下是無法將這些測試階段當作一系列獨立的活動的。通常，每次我們加入新代碼的時候，就需要同步進行這些測試。隨著項目團隊（及測試）規模的擴大，測試也變得無法"自我描述（self-documenting）"。項目的參與人越多，項目就越容易受到各種對說明文檔的不同解釋的影響--對這些定義的誤解正是導致失敗的原因。
隨著項目規模的增大，需要編寫的測試代碼也就越多。任何測試代碼都需要在應用的整個生命周期中得到支持--這極大地增加了維護的難度。
隨著測試負擔的提高，項目需要增加自動測試來最小化人力干預并減少進行這些測試所需的時間。
10． "開發人員與測試人員，是油與水的關系"
開發人員與測試人員自誕生之初就是"他們與我們"的關系。這通常是一種健康的共生關系。如果處理得當，兩個團隊之間互助的關系可以為客戶提供更高質量的產品。
應該重點討論的是：
·滿足業務目標的軟件交付（滿足要求、及時、并且控制在預算內），而不是誰控制過程中的哪一部分。
·需求采集階段測試人員怎樣參與到TDD過程中？
·測試人員如何最大程度地重用開發階段中創建的資產？
·TDD中有沒有"傳統的測試人員"？他們（就像開發人員）是否應該學習新技能以適應新的范例？
·測試人員與開發人員在利用先進的軟件開發和測試工具的時候如何發揮互助的作用？
正如開發人員的軟件工具和方法使開發方式發生了轉變一樣，下一代自動測試工具也為測試人員帶來了新的機遇，使他們可以在交付周期中更早地進行自動測試而不會遇到傳統的自動測試工具所帶來的繁重的腳本維護負擔。
總結
敏捷項目實際上是讓QA部門引領敏捷過程的好機會——沒有人比他們能更好地將用戶與開發人員聯系到一起、了解兩者的要求、滿足他們的要求并保證在部署之前完成所有工作。QA除了要繼續保證整個系統的進展能夠滿足業務目標并符合要求，他們還應該在決定結果及怎么做上有優先權利。這需要QA人員能夠靈活應變，拋棄原有的范例并集中精力研究技術以獲得最優的測試方法。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
