敏捷測試推進工作筆記（一）

　　【從這篇文章開始，我打算在本專欄中記錄本人在組織中推進敏捷測試的工作過程，這篇文章描述的是從5月到8月共3個月內的主要工作。在兩個月的時間內，我們初步決定了發展方向，在敏捷測試的氛圍建設方面都有了一些進展。2個月中主要的工作是：團隊改造，工具體系搭建，建立了初步的開發和測試的尊重和良性互動，開始在少數項目中使用自動化測試建立更好的反饋機制和提升效率】

　　2011 年4月，我離開了原來的團隊，加入了一家200人左右的互聯網創業公司(以下簡稱H公司)并擔任該公司的Engineering VP職務。我負責的團隊包括一個產品開發團隊，測試團隊和其他兩個團隊。離開一個成熟的敏捷環境，進入一個新環境，我期望能夠使用敏捷方法讓這個新公司的開發和測試部門能夠有更好的生產率和更好的工程師驅動的文化。從6月份至今，我已經在組織內推進了一些與敏捷相關的行動，從結果上看，敏捷的意識和氛圍的確向前推進了一些。當然，在我看來，創造一個更接近敏捷的環境是手段而非目的，因此，這一系列的筆記僅用來盡可能忠實的記錄我在這個組織中推進敏捷測試的方式，以及這些推動帶來的改善。

　　H 公司是一個以social game開發和發布為主要業務的公司，在我剛加入的時候，H公司的測試團隊有15人，幾乎全部成員都沒有什么技術背景，采用的測試方式是典型的手工測試。團隊使用Testlink工具管理用例和測試執行，使用Bugzilla系統進行缺陷跟蹤，自行開發了提測系統用于管理測試提交。測試人員分布在各項目團隊中，每個項目有2-4名測試工程師，測試工程師的主要工作方式是被動接受測試任務，按照開發工程師指定的測試范圍進行手工驗證。顯然，這是一個國內企業典型的傳統測試團隊，測試團隊成員充當“發現問題的最后一個環節”，以黑盒和手工測試的方法對應用進行驗證。

　　Socail game這個是一個競爭非常激烈的行業，對social game來說，快速更新和快速發布往往是一款游戲能否成功的關鍵之一。因此，對H公司來說，快速發布的能力非常關鍵。通常，開發工程師可以在一周內完成 3-4個新功能提交，但由于測試工程師需要在多個平臺和多個瀏覽器上對應用進行測試，結果測試往往成為產品發布的瓶頸。從開發工程師和產品的角度來看，測試時間太長;而如果為了縮短測試時間而僅將測試范圍定義在新功能上，測試中又會遺漏不少問題，導致結果不理想。在這種狀況下，測試工程師越來越忙，卻完全不能真正在提升產品質量方面發揮作用。

　　顯然，H公司的測試團隊采用的傳統測試流程和方法在這類要求“快速”的企業中很難適應，除非對測試團隊的行事方式與測試文化進行一個徹底的改造，測試團隊很難在組織中發揮重要的作用。

　　敏捷的推進先從團隊開始

　　團隊在敏捷中的重要性不言而喻。團隊是由個人組成的一個集體，在我看來，決定團隊的水準的，自然是團隊中的每個個體，如果一個團隊中的成員根本就不具備幫助達到這個團隊目標的能力，再有能力的領導，再好的愿景也是白扯。因此，首先需要的是從人入手改造這個團隊。這個團隊中的成員幾乎都沒有很好的開發和編碼背景，要求他們從開發的角度理解測試、理解生產率和推進自動化是不可能的事情。對他們來說，對自動化的理解很可能就是找個工具錄制一下，形成腳本，然后簡單的維護一下腳本。而我期望推進的是，建立一支真正能夠真正與開發形成良性交互，能夠幫助推動整個組織的生產率和產品質量的隊伍?？紤]到整個公司的現狀，大規模的替換測試團隊的成員是不現實的，因此，在測試團隊之外，我們新成立了一個Tools/Automation的組，這個組的目標是推進整個組織的自動化，從生產率上幫助建立自動化框架(不僅僅是測試自動化，而是整個組織的自動化和生產率)。這個組的每個成員都由我自己擔綱招聘，雖然到目前為止這個團隊只有四個人，但由于每個人的編碼和測試經驗都比較不錯，更重要的是，他們都是愛折騰，對結果負責，愿意推動事情發生的人，因此，到目前為止他們在推動敏捷測試環境方面發揮了主要的作用。

　　除了建立新的團隊外，提高原有團隊的招聘標準是另一個手段。雖然各個項目組在新功能更新頻繁的情況下，不斷的要求增加新的手工測試工程師，但在我的堅持下， “新進入的測試工程師必須要求具有一定的編碼技能和知識背景”這一條要求還是能夠得到滿足。當然，項目組缺人的問題是必須要解決的，因此我主要依靠在項目中可以明確看到結果的逐步的自動化測試推進讓項目組意識到依靠自動化測試解決他們的問題比依靠手工測試有效得多。此外，在整個團隊中不斷要求和灌輸“測試價值”的理念，使得開發和測試工程師都能認識到單純的以“發現缺陷”為目標的測試文化是很難在現有環境中產生價值的。

　　自動化推進

　　這里所說的自動化，并非僅僅意味著“自動化測試”。誠然，自動化測試是敏捷測試的基礎，但采用自動化技術讓產品發布自動化、讓不同層次的測試都存在執行的基礎，這樣才可以將開發和測試工程師納入到敏捷測試的同一陣營中來。

　　為項目建立自動化的構建環境和持續集成環境

　　每個項目最少需要有自動化的構建環境和持續集成環境。哪怕持續集成中僅包含一個測試用例，持續集成也至少可以讓整個開發組織能夠建立基于反饋(持續集成結果)的開發方式。而自動化的構建環境則允許開發和測試之間的協同工作變得簡單，且減少了構建過程中出錯的可能。能夠用于建立自動化的構建環境和持續集成環境的工具非常多，這里就不再贅述具體過程。

　　建立初步的代碼質量體系

　　高 質量的代碼是高質量軟件的基礎。除了對產品的測試外，從源頭開始控制代碼的質量對促進和提高產品質量也非常關鍵。Code Review是極好的進行代碼質量控制的手段，基于H公司的svn代碼庫，我們通過鉤子，加上開源的一些Code Review Dashboard工具建立了一套強制的Code Review流程，要求所有代碼必須經過Code Review后才能被check in到代碼庫。另外，Code Review系統中集成了靜態代碼檢查工具，Reviewer在評審代碼的時候可以直接看到提交代碼的靜態檢查結果報告。

　　自動化測試

　　敏 捷測試中，自動化測試是必不可少的重要環節。但是，在組織中推進自動化測試并不是一件輕松的事情。首先，如果組織的測試目標已經被固定成了“盡可能發現最多的缺陷”，如果開發工程師、甚至測試工程師自己已經習慣了把發現缺陷和工作時間當成自己唯一的評價標準，在這種情況下推動自動化測試，結果不言而喻。

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