敏捷方法已經獲得了越來越廣泛的應用。這是很容易理解的，特別是從開發人員與用戶的角度來看。
1. 用戶——系統的需求與過程上的細節問題似乎永遠也問不完，然后還要仔細閱讀大量的說明文檔，而他們明白這些文檔會成為將來法庭上的證據。
2. 開發人員——需要嚴格地遵循說明文檔而無法表達自己的想法或發揮創造性天賦。他們知道即使有更好的辦法，他們也不能更改說明文檔，否則這就會成為將來法庭上的證據。
但是對于質量保證人員來說，敏捷方法卻會帶來麻煩——在原來的理想情況下，他們只需要用既有的說明文檔來驗證"完成"的產品。要根據一個變化的背景驗證一個活動的目標是很不直觀的。這表示所使用的技術與自動化也更復雜，并且需要一個新的測試方式，一種類似于用戶和開發人員之間的關系的方式。
所有的敏捷方法都有（至少）一個共同的特征，那就是對QA職業的影響。如果所謂的影響是質量上的一次大飛躍，那倒也不是什么壞事。但是，如果決策是根據無效的范例做出的，改變就不一定能與過程同步了。對于開發人員來說，新提出的軟件開發范例以開發人員為中心可能是很平常的事。Abraham Maslow曾經說過："擅長用錘子的人喜歡從釘子的角度考慮問題。"但是作為質量保證人員，我們不能裝作敏捷開發不存在的樣子，我們必須保證那些拿著錘子的人不會去硬敲一顆螺絲。
某些人可能會對QA提出懷疑，認為測試驅動開發（TDD）才是測試的關鍵。但是，伴隨著需求和方案的發展，QA在整個過程中都是與敏捷小組直接發生聯系的，是整個測試設計團隊不可或缺的一部分。但這只是QA團隊所面臨所必須解決的眾多誤會中比較表面的一個。
對測試的誤解
最近看了網絡上所謂專家寫的文章，發現了一些對TDD與QA部門的誤解。本文將解釋部分誤區，并集中討論QA團隊要在敏捷的世界里獲得成功所必須解決的一些問題。
1． "你只需要做單元測試——TDD測試已經足夠"
對于大部分商業開發來說，根本就沒有這回事。即使是敏捷開發的強力擁護者也承認他們需要一系列的測試技術。
TDD程序設計人員需要這些測試來驗證代碼的正確性。如果需求（測試用例）解釋錯誤，那么你構建的代碼也將無法達到目標要求。
大多敏捷項目都會使用探索性測試方法（黑盒）來支持白盒測試，而不會認為這兩種技術只能選一。優秀的探索性測試可以在開發地過于深入之前發現開發人員所忽略的問題。
2． "你可以重用單元測試來創建回歸測試集"
有些TDD擁護者認為常規的下游測試（downstream testing）是多余的，因為每一行應用代碼都有對應的測試用例；他們認為重用單元測試就可以做到用戶驗收測試和回歸測試所能做到的一切。
這聽起來挺有道理，但由于某些原因，這是不現實的：TDD中的白盒單元測試的粒度與目標與下游黑盒測試的目的是不同的。
雖然單元測試的整體目標是保證代碼能夠實現所需的功能，但是回歸測試的目標是保證被改動的應用代碼不會產生意料外的效果。這兩個目標是不同的--比如，檢查一項屬性是否具有合法的日期格式，與檢查輸入域中是否存在所需的日期是不同的。單元測試工具
文章來源于領測軟件測試網 http://www.kjueaiud.com/
