測試自動化小組嘗試過另一款芬蘭同事開發的新型框架，名字叫做robotframework，如今已經開源。這個框架本身使用Python語言開發完成，用來開發可接受性測試，是關鍵字驅動的測試自動化框架，支持多種測試用例的格式，我最喜歡的是使用表格的HTML文件格式。框架非常好用，各方評價都非常高，但是由于核心的開發者都在芬蘭，杭州本地需要有人能夠進行培訓、輔導，才有可能做到快速地推廣使用。于是測試自動化小組的同事參加了該框架的高級培訓，以及如何進行入門級培訓的培訓，然后向杭州研發中心的其他同事提供培訓，幫助他們使用這個框架實現測試用例的腳本化。
測試框架的使用推廣很快，該產品線決定全面采用此框架來實現測試自動化，包括手工測試的用例也需要使用此框架來撰寫和管理。并且還專門成立了一個團隊為產品線開發庫函數，封裝操作命令，以便于測試人員們可以不必擔心太多庫函數編程的問題，快速地實現測試用例的腳本化。
但是測試自動化并不只是將測試用例實現腳本化而已，它是一個復雜的活動，同樣包含測試用例的設計、測試方案的選擇、測試驗證手段的選擇等等步驟，而且還必須考慮到在自動化執行的情況下，機器和被測對象的之間的交互方式和人不同，觀察被測對象反應的方式也不同。更不用提到腳本本身也是一種代碼，而代碼如果質量不高就會產生大量的技術債務。在缺乏編程經驗的測試人員手中就更是一場災難，他們會復制、粘貼現有的測試腳本，再做相應的修改，重復的腳本片段或是無關腳本片段的殘留物可謂是司空見慣。測試人員也漸漸地從歡迎轉變到了叫苦連天的態度，抱怨他們需要花非常多的時間調試出錯的腳本，根本就沒有時間去進行“真正的”測試。
為了能夠更好地推廣測試自動化，也為了能夠解決測試自動化所帶來的這些問題，管理層決定設立測試自動化教練的角色。我是被選定的兩位教練之一。我們所服務的對象不僅僅是參加過Scrum試點項目的那批人，還包括剛剛進行敏捷轉型不久的數百人大組織。
在培訓師和教練的工作中，我發現一些常見的問題：
● 不愿意花時間去熟悉工具：很多測試工作者參加完基礎培訓之后就不再花時間去查看工具的相關文檔，不愿意去熟悉其操作技巧以及庫函數開發，連一些非常簡單的小技巧也不知道，開發出來的測試用例很臃腫，使用的測試操作往往要耗費很多的CPU或者內存資源以及執行時間。
● 不愿意去閱讀現有的用例：由于種種原因，一些測試用例本身就非常難讀懂，導致后續接手的測試人員不愿意花時間去理解用例的設計思路，或者是去理解其中的每一步操作，往往滿足于用例運行通過即可，用例失敗時也只是以修改后用例通過為目的。
● 需求和用例間斷裂的聯系：敏捷轉型給測試工作帶來了一系列的挑戰，首當其沖的就是從需求到測試用例的整條線索如何延續。以往會比對軟件模塊的功能需求條目和測試用例，衡量測試的覆蓋率，而Scrum模式下開發的粒度是特性，無法沿用此做法。于是在此時，我們提出了Robot Case as Requirement的想法，也即利用robotframework測試用例本身描述性強的特點，來承載需求文檔的作用，而測試用例自身就是可執行的自動化腳本。
● 測試工作者失去的歸屬感：在Scrum模式下，測試工作者散布于每一個跨職能特性團隊中，很可能孤單一人，團隊里最多也就2~3個做測試的。相比以往單獨的測試部門，大家沒有了歸屬感，也不知道該找誰問問題、在哪里獲取測試相關信息以及如何提高自身的測試能力。我們也為此成立了測試社區Test Community，定期聚會，邀請大家來分享自己的心得體會，互相學習提高，還有在線論壇供大家交流，社區已經可以自我推動著持續發展壯大。
● 缺乏測試自動化理論知識：測試自動化（Test Automation）和自動化測試（Automated Test）其實是兩個不同的概念，測試自動化是包括測試計劃、測試用例設計、執行、分析、報告各個階段在內的一系列活動，而自動化測試可以看做是僅僅把測試用例的操作實現成腳本而已。缺乏測試自動化理論知識會累積測試技術債務，難以維護、脆弱易損的測試腳本就像是低質量、漏洞百出的代碼，后期的維護、修復開銷遠超過魯莽自動化所帶來的那一點點效益。
● 軟件本身低下的可測性：可測性可謂是測試自動化的關鍵，可測性不高的軟件本身就難以進行測試，測試自動化則更加依賴軟件的可測性。機器不像是人，可以通過眼睛觀察多處信息，并且找到其中的聯系，或是在腦中進行邏輯分析，從蛛絲馬跡間找到問題。測試自動化需要采取適合于機器的腳本執行、信息收集、結果分析的測試方法，一定程度上這都依賴于軟件本身要提供準確的、適量的信息。
● 測試工作者不熟悉Scrum：Scrum模式要求團隊是跨職能特性團隊，應該著手培養出通才化專家（Generalizing Specialist），通過加強團隊內的交流，開發、測試以及其他職能人員通過合作和溝通互相學習，摸索出適應迭代增量模式的工作方法。但多數測試工作者依然是按照類瀑布模式的方式工作，在Sprint前期空閑后期忙碌，來不及完成測試。當然，這也和不了解測試自動化，或是可接受性測試驅動開發有關系。
相關鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發人員
我的軟件測試之旅：（2）轉變——作為專職測試人員
我的軟件測試之旅：（3）同期——加入測試自動化小組
我的軟件測試之旅：（4）并行——自動化回歸測試
我的軟件測試之旅：（5）難點——功能改進的測試
我的軟件測試之旅：（6）跳轉——追逐新鮮事物的探險者
我的軟件測試之旅：（7）啟程——Scrum中的測試工作者
我的軟件測試之旅：（8）困難——沒有現成的測試工具
我的軟件測試之旅：（9）行動——簡化測試文檔和流程
我的軟件測試之旅：（10）貢獻——開發項流程
我的軟件測試之旅：（11）嘗試——Scrum Master