頻繁的迭代產生的測試版本很多時候是不完整的，測試員如何測試這些不完整的代碼呢?
“故事”應該從業務價值方面來定義。一個“故事”應該在一個迭代周期內完成。好的“故事”是不容易定義出來的，但是差的故事對測試人員的影響比對開發人員的影響還要大。有時候測試人員需要幫助定義“故事”。
敏捷測試的挑戰之三：可接受性測試是否過于簡單了?
測試人員如果只是做可接受性測試，只是驗證“故事”是否完整，豈不是太簡單了?這樣怎么能做好測試呢?
其實，每一個迭代都需要額外的測試，而不僅僅是局限于驗證“故事”的完整性。
在迭代測試中還要按需進行下面類型的測試 ：
探索性測試：同時學習系統、計劃和執行測試，尋找bug、遺漏的特性和改進的機會。
組合交互測試：專注于特性之間的交互。
場景測試：模擬真實世界的場景進行測試。
疲勞測試：長時間地執行軟件
業務循環測試：基于月末、季度末等業務循環的邊界來執行場景
壓力測試：對系統施加強大的壓力進行測試
敏捷測試的挑戰之四：把測試員作為項目組的一部分
把測試員作為項目組中的一員不是犧牲了他們作為一個組織的完整性嗎?
測試員一直被認為是受壓迫的對象，經常坐在一起互相訴苦、互相支持�，F在是時候結束這種情況了。測試員應該跟開發人員和分析師坐在一起，當項目組中有更多的正式或非正式的溝通時才有可能達到敏捷。
敏捷測試的挑戰之五：測試什么時候完成?
沒有專門分配的時間來完成測試，我們怎么知道什么時候測試應該結束?
敏捷測試員需要根據項目和產品的風險來調整測試�；旧蠝y試的優先級應該跟“故事”的優先級一致。BUG列表也提供了測試完整性的提示。
一個好的測試員是永遠都能找到需要完成的測試來做的。
為什么需要跟開發人員結對進行測試呢?因為開發人員對潛在的錯誤有一定的洞察力，測試員對約束和錯誤的時機有一定的洞察力。而他們在一起能使自動化測試更加成功。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
