敏捷下測試員面臨的挑戰

什麼是敏捷開發？

敏捷開發是遞增式的、迭代的、不斷調整的開發模式。我們逐漸地建立起軟體系統，能看到系統在成長，能展示進度。

通過多次發布或項目的階段檢查點，每一次都比上一次靠近目標。迭代包括需求的開發和測試，典型的迭代周期是2周。目標隨著從上一次的迭代中學到的東西、反饋以及商業機會而調整。

在敏捷開發中，工作被分解成「故事」，也叫特性或用例，組合成任務分派給不同的程序員。定義好接受標準，開發直到單元測試和接受測試通過才算完成。

敏捷開發講求合作，結對進行編程，避免個人擁有專門的知識，代碼屬於項目組共有。

在敏捷開發中不存在回退，講究持續地集成，單元測試（通常使用測試驅動的開發方式），持續地進行回歸測試。

為什麼以前的開發模式不再適用？

以前的開發模式要求有詳細的測試計劃，但是缺乏足夠的時間來寫，而且測試計劃受很多因素的影響經常改變。

以前的開發過程會專門留出一個階段來測試，但是你不能定義進入和退出的標準，測試階段會隨之而過。

以前的開發模式強調變更控制，但是現在的軟體需求變更非常頻繁，變更成了家常便飯。

以前的開發模式要求測試要對軟體做出權威的判斷，但是測試很難做出權威的關於軟體正確性的判斷。

測試的作用

有價值的東西有么提供產品，要麼提供服務。那麼測試提供什麼產品或服務呢？有人認為測試提供調試通過的、經過測試的軟體。

這是錯誤的回答。測試不提供產品，測試提供信息，關於開發過程中的軟體的狀態的信息，以便基於這些信息做出決定。

敏捷測試的挑戰之一：測試員是否不再需要了？

既然有開發人員做單元測試了，我們還需要測試員嗎？有些項目團隊採用了敏捷開發方式後把測試員都給解僱了，然後過了不久他們就後悔了。

測試可以是除QA或測試員外的人來做，例如業務分析員，有些項目團隊讓開發人員來做接受性測試。

但是有專門的測試員帶來兩個好處：

1、 專註於用戶使用而不是軟體的技術實現

2、 專註於發現軟體的錯誤而不是證明完整性

敏捷測試的挑戰之二：測試不完整的軟體

頻繁的迭代產生的測試版本很多時候是不完整的，測試員如何測試這些不完整的代碼呢？

「故事」應該從業務價值方面來定義。

一個「故事」應該在一個迭代周期內完成。好的「故事」是不容易定義出來的，但是差的故事對測試人員的影響比對開發人員的影響還要大。有時候測試人員需要幫助定義「故事」。

敏捷測試的挑戰之三：可接受性測試是否過於簡單了？

測試人員如果只是做可接受性測試，只是驗證「故事」是否完整，豈不是太簡單了？這樣怎麼能做好測試呢？

其實，每一個迭代都需要額外的測試，而不僅僅是局限於驗證「故事」的完整性。

在迭代測試中還要按需進行下面類型的測試 ：

• 探索性測試：同時學習系統、計劃和執行測試，尋找bug、遺漏的特性和改進的機會。
• 組合交互測試：專註於特性之間的交互。
• 場景測試：模擬真實世界的場景進行測試。
• 疲勞測試：長時間地執行軟體
• 業務循環測試：基於月末、季度末等業務循環的邊界來執行場景
• 壓力測試：對系統施加強大的壓力進行測試

敏捷測試的挑戰之四：把測試員作為項目組的一部分

把測試員作為項目組中的一員不是犧牲了他們作為一個組織的完整性嗎？

測試員一直被認為是受壓迫的對象，經常坐在一起互相訴苦、互相支持。現在是時候結束這種情況了。

測試員應該跟開發人員和分析師坐在一起，當項目組中有更多的正式或非正式的溝通時才有可能達到敏捷。

敏捷測試的挑戰之五：測試什麼時候完成？

沒有專門分配的時間來完成測試，我們怎麼知道什麼時候測試應該結束？

敏捷測試員需要根據項目和產品的風險來調整測試。基本上測試的優先順序應該跟「故事」的優先順序一致。

BUG列表也提供了測試完整性的提示。

一個好的測試員是永遠都能找到需要完成的測試來做的。

為什麼需要跟開發人員結對進行測試呢？因為開發人員對潛在的錯誤有一定的洞察力，測試員對約束和錯誤的時機有一定的洞察力。而他們在一起能使自動化測試更加成功。

測試員應該自動化可接受性測試，使用與開發環境一樣的編程語言來編寫可接受性測試的代碼，重用單元測試的框架，使軟體更加可測。

利用「灰盒」測試。設法弄清楚系統各模塊之間的關係，分析變更的影響，看什麼是需要測試的，什麼是可以不測試的。

弄清楚bug，bug的表面現象是什麼？產生bug的根本原因是什麼？弄清楚風險，使用解決風險的測試策略，調整測試目標。

敏捷測試的挑戰之六：我們還需要bug跟蹤系統嗎？

有些人說敏捷團隊不需要跟蹤bug，只需要把發現的bug儘快修正就行了。

這種做法只適用於開發過程的測試，如果是一個完整迭代的測試，你就需要bug跟蹤系統，因為有些bug不是在這個迭代馬上修改的。

敏捷測試的挑戰之七：用什麼質量標準來度量敏捷項目？

其中一個最好的質量標準是發布後逃逸的bug數量。不辛的是，這是個事後的衡量標準。

採用每個迭代後計算逃逸bug數量的方法能標識代碼的質量。

我們還可以從bug學習到很多東西：

• 是否有些類型的bug在可接受性測試中發現的，其實是可以在單元測試就發現呢？如果是，把它加入到單元測試。
• 我們是否能讓bug的發現過程或bug的診斷更簡單？
• 我們是否能讓程序員不那麼容易犯這種普通的錯誤？

敏捷測試的挑戰之八：回歸測試

伴隨著頻繁的迭代，我們需要頻繁地重新測試，單元測試是不足夠的。我們怎樣有效地進行用戶層面的回歸測試呢？

你不一定需要在每次的迭代都做完整的回歸測試。可以每個迭代運行一部分的測試。需要某種程度上的用戶層次的自動化回歸測試。