在Agile Practitioners 2016大會上，Huib Schoots談了可測試性。他指出，低可測試性（任何導致軟件難以測試的東西）會導致團隊效率低下，并探討了如何提高可測試性。

Schoots談了軟件開發中未知的未知問題。我們無法掌握開發一款產品需要提前完成的一切工作，因此，我們必須確保在軟件開發過程中構建洞察力。我們必須知道如何應對復雜性和不確定性?！翱刂婆c命令”式的瀑布方法會成為構建洞察力的障礙。

敏捷測試是在敏捷環境中測試。測試不會因為我們采用敏捷而改變，變的是環境。敏捷測試有一些不同，它使用迭代方法，準備提前期變短，測試執行和報告生成變快，而變化非常常見。此外還有角色的變化，Schoots提到，使用敏捷時，測試經理更多的是一名教練，只做較少的測試。

Schoots表示，快速測試是一種測試理念和綜合技能?？焖贉y試可以減少文檔，將更多的精力集中在如何測試上。快速測試是一種通用的測試方法，不僅適合敏捷，也適合任何的項目或產品。

測試是指人們在不確定的情況下通力合作。我們不可能什么都知道，而事情總是在變化。

Schoots表示，測試的目的是了解產品的狀態以及任何威脅產品價值的因素，以便客戶可以做出明智的決策。測試人員能夠看到事情的真相，并照亮前進之路。他們會把真相告訴團隊和項目經理。

檢查（與測試相對）是指操作一款產品檢查具體的輸出。按照Schoots的說法，所有的檢查都應該盡可能地自動化。檢查非常繁瑣，自動化可以提高可測試性。

Schoots提到了James Bach對可測試性的定義：

產品實際的可測試性是指在特定的環境中，產品被特定的測試人員及測試過程測試的難易程度。

按照Schoots的說法，我們需要可測試性，因為它可以簡化測試，提升測試速度，降低測試成本及減少不可再現的Bug。

Schoots講了一個故事，是關于一家他工作過的銀行。他們不能使用生產環境的代碼進行測試。因此，他們必須創建文本文件來測試錢在“測試銀行”之間的轉移。Schoots目睹了測試人員如何手動修改一個用于測試的大文本文件。由于這耗費了太多時間，所以他們決定構建一個工具用于這種修改。經過擴展之后，該工具能夠做使用生產環境代碼作為輸入創建測試文件所需要的所有修改。借助這款工具，測試人員每天節省了大約三個小時，因此，這款工具提升了可測試性。

認知可測試性是指我們知道的東西同我們需要知道的東西之間的差距。認知測試需要具備產品質量的先驗知識。據Schoots介紹，測試等待的時間越長，差距就越大。一個例子是，了解什么功能已經在單元測試中進行了測試，如果有了這樣的知識，那么就不需要在系統測試中再次對它進行測試。

James Bach認為，測試人員必須要求可測試性。Schoots對此并不完全贊同，他的觀點是，測試人員應該要求更高的可測試性，因為那是一種團隊職責，整個團隊都會從高可測試性中受益。

Schoots表示，高可測試性使測試更快、更簡單，同時成本更低，每個人都可以從中受益。他建議將可測試性作為沖刺計劃的一個主題，團隊應該進行可測試性回顧，找出提高可測試性的方法。

查看英文原文：How Testability Can Help Teams to Go Faster