“敏捷測試”是什么?

　　又一次，關于“敏捷測試”到底是什么的討論熱鬧起來，小編自己經歷過很長時間的實踐，后來也開始輔導團隊、企業實踐敏捷測試，現在就跟大家分享一下這些經驗。

　　敏捷軟件測試領域的權威作品，無疑是名稱最符合的《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》，原作名《Agile Testing: A Practical Guide for Testers and Agile Teams》，作者是Lisa Crispin和Janet Gregory，推薦大家閱讀。

　　如下是小編的一些看法：

　　敏捷軟件測試就是在敏捷方式下開展測試工作的方式，是一種方式，而不是測試的類型、范圍或階段。

　　所以敏捷測試的專家，一定是整個測試方式的專家，意味著要涵蓋測試類型、測試范圍、測試階段這幾個維度，那通常就是整體或全局的顧問了，可以看作是傳統所說的“測試流程顧問”，但因為敏捷里面，測試跟開發和其他環節密不可分，所以這個“流程顧問”只懂測試是遠遠不夠的。

　　通常業內把敏捷測試當作是一種類型，例如，把敏捷測試看作是功能測試之后、性能測試之前執行的一種類型的測試，這就是誤解。

　　手工、自動的區分，測試出身的都不一定搞得清楚，更不要說非測試出身的了。涉及到探索式測試，就更容易混淆，手工、自動，通常是指執行的手段，探索，指的是測試的目的。這意味著手工的測試不一定就是探索式的，而探索式的測試也不一定就是手工的。

　　雖然敏捷到底意味著什么，業內也有爭議，但較為廣泛接受的是從需求到產品的全過程，更全的是從概念到現金(from concept to cash)的全過程。

　　讓開發人員專注于開發，讓測試工具(谷歌的工程生產力)人員專注于提供支持測試(和其他生產力活動)的工具，讓測試人員專注于研究如何用工具快速高效地完成業務的驗證，才是一個合理的模式

　　當然，取決于這三類人群的心智模式的距離，距離越近的，這三類人群的分隔越不清晰，也更容易一個人搞定所有。心智模式越遠的，越需要清晰的界限，也即三類人員， 然后強調緊密合作。我這個理念，我覺得在《設計心理學》里是有共鳴的，我們能夠做好工作，取決于我們每天所接觸的東西，與我們要完成任務所需的概念模式，是容易建立關聯、檢測進度和獲取反饋的。這就是我說的心智模式。

　　如果最終產品和代碼或程序的理念很像，那么程序員搞定一切，一點問題沒有，例如程序員開發給程序員用的工具，因為他們本身就是用戶，所以程序員搞定從開發到測試的所有任務，一點問題都沒有。

　　如果最終產品運行的概念模式和構成單元(代碼)的心智模式差距很遠，那么程序員就不可能搞定一切。例如，銀行的對公業務，作為程序員，最熟悉的是代碼和代碼運行的概念模式，而對公業務的基礎構造單元和概念模式，則與之有很大的差距，想要依靠程序員完成對最終產品的完美驗證，幾乎不可能，或者說，會帶來分裂和效率問題，因為要想形成對代碼或業務的高度理解，是試圖同時追求知識的廣度和深度，要么就是不可能做到，要么就是浪費，帶來極大的心智切換成本。

　　尤其是當涉及人員很多的時候，必須考慮分工。開發專注編寫代碼，但從需求到設計(需要實現哪些代碼)的過程的合理性就很重要;測試專注理解業務從而合理地驗證產品功能，但從頭介入防患于未然就很重要;而提高效率則需要靠提供工具，工具需要開發，屬于代碼的概念模式，而工具的使用者又是我們希望更側重業務的測試人員，屬于業務的概念模式，好在這兩塊都不需要非常深的理解，所以我們需要專門的工具開發人員。這種分隔，就在不同類型的專業(=專職，請注意理解)人士和知識的深度、廣度之間找到了平衡，當然，最重要的是一定要緊密協作，才能夠解決問題。

　　另一方面就是原來那么多級的測試，如何處理，敏捷的思路是要針對更小的需求顆粒度，在迭代內完成所有相關類型、范圍的測試(階段跟時間有關，敏捷方式跟傳統不同，打破了時間安排，所以階段是完全不同的)。

原文轉自：http://www.testwo.com/article/585