敏捷測試：反學習的關鍵

　　“懂得如何反學習的人學得最快。”

　　——作者不明

　　當QA團隊和管理層剛剛開始運用敏捷的實踐的時候，他們通常會遇到如何將傳統的并且在他們腦海里已經根深蒂固的思想和實踐忘掉的問題。

　　下面是一些從QA的角度出發，在實施敏捷實踐之前需要忘卻的一些關鍵點：

　　測試團隊需要是獨立團隊，并且能夠獲得足夠的授權才能變得高效

　　如果沒有獨立的測試策略和測試計劃的話是很難進行測試管理的

　　在敏捷sprint中無法與用V模型

　　獨立的測試團隊不需要做白盒測試

　　只有能夠發現BUG的時候才能夠體現測試的價值

　　測試自動化不是必須的，而且只有在回歸測試的時候才需要

　　在一個sprint中是無法進行系能測試等非功能性測試的

　　測試必須按照：計劃、規格、執行和完成的順序進行

　　不需要為已發現的BUG寫新的測試用例

　　只要代碼能夠實現所需的功能，測試團隊就不用計較代碼的質量

　　測試流程改進模型并不適用于敏捷測試

　　接下來讓我們來把上面的這些觀點一個一個地審視一遍：

　　測試團隊需要是獨立團隊，并且能夠獲得足夠的授權才能變得高效

　　傳統上來說，測試團隊可能有以下這些組織結構：沒有獨立的測試團隊依靠開發人員進行測試;測試人員在開發團隊里面;由公司中專門的部門來進行測試——甚至可能是把測試外包出去。通常來說，測試團隊希望能夠直接匯報給高級項目主管，而不是報告給開發團隊或者TL。他們的初衷是希望在提交BUG的時候不會被TL阻撓。

　　在敏捷思想中，測試人員必須是團隊中的一員。他們應該專注的是，在沒人任何技術債務的前提下，在每個sprint結束的時候交付質量過關的可交付產品，從而滿足團隊承諾的代辦列表項的“完成”條件。測試人員要向敏捷團隊匯報，而且要對PO和業務需求負責。

　　如果沒有獨立的測試策略和測試計劃的話是很難進行測試管理的

　　通常測試策略的文檔都是集團級的，公司級的或者是部門級的，至少也是產品級的。很少有人會為一個單獨的項目設立測試策略，除非這個項目要持續很多年，所以為某個項目專門設立的策略通常會記錄在該項目的測試計劃里。

　　在敏捷項目中，測試方法可以記錄在發布計劃中，而針對每個sprint的測試活動應該在sprint計劃會議的時候記錄下來，因此很有可能不需要獨立的測試計劃。然而，擁有高于項目層面的測試計劃是非常有用的，尤其在公司在向敏捷轉型的過程中。在測試策略中，可以記錄測試的實踐、和在集團或者分公司中需要遵循的規則。然后，敏捷團隊可以在為項目的發布計劃定義的測試方法中應用其中的一些實踐。

　　在敏捷sprint中無法與用V模型

　　在sprint中，驗證和檢查都是通過敏捷實踐來實現的，例如驗證需求已經按照INVEST的形式記錄;編寫和評審涌現的文檔和簡單設計;評審視圖建模;舉行每日站會;進行持續集成;進行代碼重構;利用自動化測試進行開發測試和驗收測試;增進和PO以及客戶的交流。

　　下圖中展示了敏捷中的V模型和傳統的V模型關于驗證和檢查之間的區別：

　　獨立的測試團隊不需要做白盒測試

　　傳統上，獨立的測試團隊專注于黑盒測試，而對底層的測試不屑一顧。然而，在敏捷項目中，測試人員在自動化開發測試和驗收測試中扮演著非常重要的角色。敏捷測試通常是持續性的，而非階段性的。敏捷的測試人員需要懂得設計以及了解代碼層面的知識才能更有效地在一個sprint中進行測試。通常開發人員主導單元測試，而敏捷測試團隊參與部分的底層測試以及主導自動化測試。

　　只有能夠發現BUG的時候才能夠體現測試的價值

　　測試的價值不光在于檢測出多少個BUG，還在于能夠保證可交付的產品的質量是足夠好的。敏捷團隊需要忘記從前那套以找BUG個數為上的思想。團隊可能以為找到越多的BUG就證明績效越高，結果導致了系統中記錄了很多瑣碎的BUG。

　　敏捷測試團隊直接對產品待辦列表項目的狀態負責，也就是說，如果一個代辦列表項沒有通過測試的話就不能認為其已經完成。敏捷測試團隊要多利用各種展示板來展示各個代辦列表項的狀態。

　　測試自動化不是必須的，而且只有在回歸測試的時候才需要

　　自動化測試不是可有可無的，相反，自動化測試是非常重要的部分，尤其是需要加快一個產品推向市場的時間的時候。一個以最高速率前行的敏捷團隊，會應用持續集成、自動化開發測試、自動化驗收測試等工程實踐。如果沒有了自動化測試和工具的使用，那么團隊就不能稱之為敏捷團隊。

　　在一個sprint中是無法進行系能測試等非功能性測試的

　　有時候，有可能無法在一個sprint中完成系統性能測試等非功能性測試。然而，這個問題可以通過在發布計劃中加入一個單獨的發布sprint來解決。發布sprint可以用來進行非功能性需求的測試，也可以進行一輪驗收測試來驗證在BUG修復后系統還能正常運行。如果有實施持續集成和自動化測試的話，那么也許就不需要嚴謹的集成測試了。

　　測試必須按照：計劃、說明書、執行和完成的順序進行

　　雖然計劃、說明書、執行和完成都和敏捷測試息息相關，但是我們需要記住的是敏捷測試是一個持續性的過程，而不是階段性的。例如，當一個待辦列表項已經標志為完成的時候，很有可能另外一個待辦列表項還處于編寫說明書的階段。有些團隊會在把當前待辦列表項的測試用例都用自動化實現了以后才將該項標識為“完成”。

　　不需要為已發現的BUG寫新的測試用例

　　在傳統上，如果測試團隊在探索性測試的過程中發現了BUG，團隊并不會回過頭來為這個BUG創建一個新的測試用例。不這么做的一個關鍵原因是，改變測試文檔的流程需要改變計劃好的測試基準。然而，適應變化正式敏捷框架的一個基礎組成部分。在敏捷測試中，如果一個BUG沒有對應的測試用例，那么就要為這個BUG編寫新的測試用例，然后再把新的測試用例添加到自動化測試中。

原文轉自：http://www.anti-gravitydesign.com