敏捷測試的挑戰 軟件測試
我們從上下文驅動測試的七大原則(www.context-driven-testing.com)可以看出，上下文驅動測試傾向于快速的反饋和適應變化的環境。所以上下文驅動測試的很多原則和做法可以應用到敏捷開發的軟件測試中來。
什么是敏捷開發?
敏捷開發是遞增式的、迭代的、不斷調整的開發模式。我們逐漸地建立起軟件系統，能看到系統在成長，能展示進度。通過多次發布或項目的階段檢查點，每一次都比上一次靠近目標。迭代包括需求的開發和測試，典型的迭代周期是2周。目標隨著從上一次的迭代中學到的東西、反饋以及商業機會而調整。
在敏捷開發中，工作被分解成“故事”，也叫特性或用例，組合成任務分派給不同的程序員。定義好接受標準，開發直到單元測試和接受測試通過才算完成。
敏捷開發講求合作，結對進行編程，避免個人擁有專門的知識，代碼屬于項目組共有。
在敏捷開發中不存在回退，講究持續地集成，單元測試(通常使用測試驅動的開發方式)，持續地進行回歸測試。
為什么以前的開發模式不再適用?
以前的開發模式要求有詳細的測試計劃，但是缺乏足夠的時間來寫，而且測試計劃受很多因素的影響經常改變。
以前的開發過程會專門留出一個階段來測試，但是你不能定義進入和退出的標準，測試階段會隨之而過。
以前的開發模式強調變更控制，但是現在的軟件需求變更非常頻繁，變更成了家常便飯。
以前的開發模式要求測試要對軟件做出權威的判斷，但是測試很難做出權威的關于軟件正確性的判斷。
測試的作用
有價值的東西有么提供產品，要么提供服務。那么測試提供什么產品或服務呢?有人認為測試提供調試通過的、經過測試的軟件。這是錯誤的回答。測試不提供產品，測試提供信息，關于開發過程中的軟件的狀態的信息，以便基于這些信息做出決定。
敏捷測試的挑戰之一：測試員是否不再需要了?
既然有開發人員做單元測試了，我們還需要測試員嗎?有些項目團隊采用了敏捷開發方式后把測試員都給解雇了，然后過了不久他們就后悔了。
測試可以是除QA或測試員外的人來做，例如業務分析員，有些項目團隊讓開發人員來做接受性測試。
但是有專門的測試員帶來兩個好處：
1、 專注于用戶使用而不是軟件的技術實現
2、 專注于發現軟件的錯誤而不是證明完整性
敏捷測試的挑戰之二：測試不完整的軟件
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
