靈活軟體開發是從1990年代開始逐漸引起廣泛關注的一種新型軟體開發方法，是能夠應對快速變化的需求的一種軟體開發能力，它作為一種新型的開發模式，被越來越多地應用到軟體項目中。
靈活軟體測試指的是在靈活軟體開發過程中跟品質相關的一系列活動，和傳統意義上的軟體測試有很多差別，因為靈活軟體測試的概念一直比較模糊，是以經常會有人走入誤區，我曾經在瀑布型的軟體開發模式下做過幾年的測試人員，是以在剛剛接觸靈活項目的時候也曾有過一些誤解，但是在靈活軟體開發團隊工作将近5年後，對很多問題有了新的認識，以下針對幾個常見的誤區和大家分享一下我的了解。
不需要測試政策
測試政策關注的是目标和方法，即怎樣在限定的時間内有效利用有限的資源達到提前制定的目标，一般制定測試政策時會首先明确測試目标，然後确定需要哪些測試類型，各種測試類型所占的大概比例，選擇測試架構，最後規劃一下軟體釋出前需要經曆哪些測試階段。
很多人認為，靈活軟體開發以使用者故事為單元，是不是集中精力在使用者故事測試就足夠了？是不是根本不需要考慮測試政策？
其實這是一個很大的誤解，因為靈活軟體開發通常都是疊代式的釋出，周期比較短，資源非常有限，這就更需要我們統籌規劃，小到一個使用者故事，大到一個完整的使用者特性，都需要考慮怎麼合理利用測試資源，是以靈活項目是非常需要測試政策的。
具體到實際項目中，通常團隊會在項目初期（疊代0）制定測試政策，明确目标(包括功能性需求的目标以及非功能性需求的目标)，然後确定在開發階段需要添加哪些自動化測試(包括單元測試，接口測試，契約測試，內建測試，系統級别的ui的使用者場景測試)，并規定這些測試的大概比率(符合測試金字塔)，選擇自動化測試架構（比如xunit）以及需要哪些手動測試(包括探索性測試，可用性測試等)，還要規劃每個釋出周期需要進行的測試階段（比如新功能測試，回歸測試等），之後測試政策會對靈活團隊的開發及測試起到非常重要的指導作用，當然，每個團隊因為項目的不同政策也會不同。
下圖就是一個簡單的靈活測試政策介紹：
不需要測試文檔
測試文檔通常包括測試計劃，測試用例，測試報告，測試缺陷等文檔以及相對應的可以指導測試的一部分需求文檔。
很多人會認為，靈活軟體測試是不需要文檔的，靈活宣言中有一句“工作的軟體 高于 詳盡的文檔”，盡管靈活宣言最後提到了“右項也有價值，我們更重視左項的價值”，但人們往往會忽視右項的内容，導緻在很多剛開始實施靈活開發的團隊中完全否定了測試文檔的作用。
首先不可否認，在實際的靈活項目中，确實很少見傳統意義上的正式的專門的需求文檔和測試文檔，但這并不代表靈活項目沒有文檔，比如使用者故事本身就是需求的載體，使用者故事中的驗收條件就是靈活測試文檔的一部分， 另外很多靈活軟體項目都會采用bdd的方式進行開發，将測試用例用業務人員能夠看懂的自然語言描述，并結合自動化實作，形成一個融需求和測試為一體的文檔，而且為了應對靈活軟體測試變化快文檔更新不及時導緻的問題，很多靈活項目都在使用living document。
純自動化測試 or 純手動測試
有些剛接觸靈活的人認為靈活軟體開發釋出周期很短， 測試人員根本沒有時間做手動測試， 是以應該采用純自動化測試。
也有一些人認為，靈活開發強調快速響應變化，如果投入成本在自動化測試上，那麼肯定會導緻維護自動化測試帶來的資源浪費，是以應該采用純手動測試。
這是兩種極端的誤解，雖然這兩種觀點所考慮到的難點确實存在， 因為在靈活軟體開發過程中， 疊代通常比較短，确實不會預留足夠多的時間來做手動測試， 是以必須要有足夠多的自動化測試來保障。
然而因為測試代碼本身可能存在缺陷，而且有很多部分難以被自動化測試覆寫(比如界面的測試，可用性測試，探索性測試等)，是以靈活測試也同樣離不開手動測試。
至于關于自動化測試維護成本的顧慮，靈活項目也确實存在變化比較多的特點，但通常變的都是比較接近使用者的部分，是以應該盡量減少使用者級别的依賴界面的自動化測試，而多增加一些不容易變化的底層的單元測試接口測試等。
推薦靈活測試以自動化測試為主，手動測試為輔。
靈活qa = 靈活tester
在很多剛接觸靈活實踐的團隊中，大家對靈活qa的認識還停留在tester的階段，認為隻要使用者故事開發完成之後，qa去專職地做測試，發現缺陷就夠了。
這是一個很大的誤解，首先qa(quality assurance/analyst)，不是單純意義的測試人員，通過這個角色的名稱我們可以看的出來靈活qa強調的是品質保障和分析，而不單純是測試産品。
在實際的項目中，靈活qa通常會從需求分析階段就開始參與整個軟體開發過程，通過在不同階段和團隊中的不同角色合作，幫助整個團隊對品質達成共識，并通過在不同階段的确認和驗證做到缺陷預防，而不是等到軟體開發完成後再去發現缺陷，是以對于靈活qa來說，其目标是軟體開發完成後能夠發現的缺陷越少越好，而對于tester來說，發現越多的缺陷證明工作做得越優秀。
非功能性測試不重要
非功能性測試指的是針對非功能性需求（軟體本身滿足使用者需求所必需的功能性需求以外的一些特性，比如安全，性能，可用性，相容性等）的測試，通常包括安全測試，性能測試，可用性測試，相容性測試等。
在靈活軟體項目中，需求被切割成了很小的單元，在切割的過程中，非功能性需求是最容易被人忽略的一部分，而這導緻的問題就是非功能性測試經常被團隊忽略，久而久之，就會形成這樣一個誤解，認為非功能性測試是不重要的。
這個觀點非常不對，首先非功能性測試的重要性并不會因為軟體開發模式的不同而有所不同，尤其安全測試和性能測試的重要性正越來越多地被重視起來，因為很多産品必須考慮到使用者敏感資訊的安全以及性能導緻的使用者滿意度，在靈活項目中由于軟體會盡早釋出，如果這些非功能性需求出現問題，就會更早地造成影響，很可能在軟體剛步入市場就損失掉大多數的使用者。
是以非功能性的測試和功能性測試同等重要，在實際的項目中，比較好的做法是将這些非功能性需求也加入到使用者故事的驗收條件中，在整個靈活開發流程中對這些非功能性需求進行驗證。
品質是qa的事兒
受傳統觀念的影響，很多人還是會認為品質是qa的事兒，如果産品釋出後品質不好是qa的問題，其他角色和品質沒有太大的關系。
首先這種認識太高估了qa對品質的作用，軟體的品質是在軟體開發過程中逐漸形成的， 從需求分析階段是否真正的了解到了客戶想要的功能，到開發階段是否增加了足夠多的自動化測試保障，是否寫了足夠健壯的産品代碼，到最後測試階段是否測試了功能引入後整個系統的可用性，不同使用者路徑是否能正常工作等等，這些都是軟體品質的組成部分。
可以看得出來，在整個過程中，軟體的品質離不開靈活團隊各種角色的付出，其中有業務分析人員對需求的準确把握，有開發人員對産品代碼的高标準實作，對自動化測試覆寫率的保障，還有qa在整個過程中對品質相關活動的實施和保障，包括需求分析階段從qa的視角對業務的補充，開發階段對自動化測試的審查，以及探索性測試可用性測試等對産品品質的進一步保障。
是以在靈活測試中更多時候我們會淡化角色的概念，強調團隊人人都為品質負責，這樣更有助于團隊的每一位成員都把品質作為非常重要的一部分，而不是依賴于某個人或者某個角色。
開發可以寫測試，不再需要qa了
因為靈活團隊強調人人都為品質負責，開發人員會采用tdd等方式寫大量的自動化測試，那麼是不是就不需要qa了？
對于這個觀點，在社群有過很多激烈的讨論，比如這篇文章《我們需要專職的qa嗎？》就曾經引起了很大的争議，其實個人認為這篇文章裡提到的qa指的是tester，具體兩者的差別可參考前面的觀點；抛開這個，作者的某些觀點其實是很有價值的，比如作者最後提到了品質不是測出來的，要通過軟體生命周期各個階段相關活動的保障，而這些活動都離不開qa的參與。
首先需求分析階段，qa可以從不同的視角對于需求提出疑問，補充，修改，因為qa特有的技術背景，對于軟體的可用性等有更深入的了解，是以往往可以提出不同于業務分析師和開發人員的觀點；開發階段，qa也會審查開發人員寫的自動化測試，通過qa的專業測試背景幫助開發人員寫更有價值的測試，比如我們在項目中曾經發現開發人員寫了很多沒有業務價值的測試；測試階段，探索性測試，可用性測試，安全測試，性能測試等都是qa們在做的事情。
當然，如果業務分析師從各種視角把業務分析的透徹完美，開發人員可以寫非常有價值的測試，也可以做各種類型的手動測試，那麼去掉專職qa也不是不可以，那樣的話不是不需要qa，而是人人都是qa。
結論
以上列出來的七點是剛剛接觸靈活測試時很容易進入的誤區，甚至有的觀點在一些已經施行靈活很長時間的團隊中仍然存在，這些觀點很容易導緻靈活測試走上彎路，以上是結合實際項目經驗個人的一些思考，希望對大家有所幫助。