案列：當開發人員需要對功能進行比較大的修改，估計需要兩天時間才能完成程式碼，這時測試人員反對這樣做，本來只有5天測試時間，驗收測試已經很緊張。如果再延遲兩天，測試沒法完成。而產品經理認為，你們不是在用敏捷測試方法，應該測得很快，三天應該能完成測試工作啊!

敏捷測試當然不能簡單地理解測得更快，絕對不是比以前用更少時間進行測試，也不是將測試的範圍縮小了或將質量降低來減少測試任務。

敏捷測試應該是適應敏捷方法而採用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有所不同的側重，例如減少測試計劃、測試用例設計等工作的比重，增加與產品設計人員、開發人員的交流和協作。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的迴歸測試則依賴於自動化測試。由於敏捷方法中迭代週期短，測試人員儘早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟體產品質量進行反饋。

在敏捷方法中，需求變化比較快、產品開發週期很短，我們目前採用四周時間，也就是每個月釋出一個新版本。開發週期短，功能不斷累加，給測試帶來很大的挑戰，測試流程要做相應的調整。

在對新功能進行app功能測試和迴歸測試策略上，測試任務簡單地可分為新功能測試和迴歸測試。在敏捷方法中，針對這兩部分的測試建立相應的策略，加上自動化測試，以提高測試的效率，最大限度地降低質量風險。

不需要測試用例，直接基於用例、基於對需求的理解來完成新功能的驗證。即使要寫測試用例，只要保證各個功能點被覆蓋，不要過於詳細。

持續地進行驗證，一旦某塊新程式碼完成, 就開始驗證，而不是等到所有程式碼完成後才開始測試。這也包括參與到單元測試和整合測試中。

實施端到端的測試，確保完整的業務流程的實現，同時，也容易發現業務邏輯不夠清晰、不夠合理等各方面的問題。

閱讀程式碼來發現問題，可以和開發人員工作保持同步，消除測試周期的壓力。

基於經驗，可以實施更多的探索性測試、組合互動性測試和使用者場景測試，更有效地發現埋藏較深的缺陷。