一、導讀

品質中心近半年提出了外包人員效率優化的口號。各個測試團隊積極響應，想出各種各樣的辦法來嘗試節省人力。其中“外包資源池管理”是各個團隊都沒有放過的一種嘗試手段。

其最初的理念是把各個項目中一些簡單的任務識別出來，交給一波初級的外包去做。這樣能解決部分外包工作不飽和問題以及降低外包的培養成本。

而在不同測試團隊的具體實施中，又演化出不同的實施方案。本文記錄手機QQ瀏覽器測試團隊在“外包資源池管理”方案上的幾次嘗試。有沉痛的教訓，也有深度的思考。

二、資源池管理的預期收益

1、外包人力的充分利用

當前外包利用不充分的情況主要有2種形式。一是任務潮汐現象導致在任務量少的時候外包工作不飽和。而因爲管理或者能力上的割裂不能很好地把這些閒置的人力給利用起來。手機QQ瀏覽器測試團隊也存在這個問題。希望能通過資源池的管理方式解決。二是由於缺少統計和管理導致的人員閒置與低效。這個問題手機QQ瀏覽器測試團隊不多見。在這裏不展開。

2、外包培養和管理的成本下降

目前外包的培養和管理職責都是落在測試經理頭上的。如果外包資源池能夠分擔甚至包管了這部分職責，測試經理就可以把更多的精力放在產品測試本身。對項目質量以及測試經理的個人成長都有利。

三、手機QQ瀏覽器測試外包團隊特點

1、項目割裂

手機QQ瀏覽器分爲iOS瀏覽器、Android瀏覽器、TBS瀏覽服務3個大產品。具體分工上，又分爲iOS測試、後臺（小說、視頻、資訊、廣告等）測試、Android內核測試、Android UI測試、Android性能測試、TBS測試、視頻文件測試7個小組。地域上也分爲深圳、成都、合肥3個地方。

項目的割裂代表着業務和技能的割裂。比如說，讓一個測後臺的同學去理解理解TBS的下載安裝流程會很費勁；而讓熟悉android手機抓網絡包的同學去抓iOS手機網絡包也要學習半天。這種割裂會讓一個外包同學掌握多個測試小組的需求和技能變得十分困難。

2、任務難度大

任務難度大的問題在Android瀏覽器的幾個測試組裏體現明顯。我們按照任務需要的技能要求將任務分成高中低三檔。據粗略統計，QB主線高難度任務佔比爲44%；TBS高難度用例佔比爲33%。這些高難度的用例通常以下特徵：

1）涉及前端、終端、後臺多方面配合；

2）無法通過終端界面驗證結果；

3）測試中會遇到很多意外情況需要靈活處理；

4）需要用到一些生僻、複雜的測試工具，如inspector、fiddler等。

以廣告過濾爲例，需要先確認拉取到wup後臺的開關，瞭解廣告過濾功能的開關狀態，然後向業務後臺拉取訪問站點的過濾規則，接着終端要對該規則進行處理。過程中每個環節的結果都無從通過終端界面驗證結果，而要通過查看日誌、配置文件、上報等方法。

3、人力緊張

各個測試組都沒有長時間的閒置人力。特別是2017年上半年，iOS、後臺、TBS都新增了不少業務。這半年的外包工作飽和度明顯比之前更高。這樣就不可能有閒置人力可以參與到資源池建設中。

從以上3點分析，我們一度悲觀的認爲，外包資源池管理不適合我們團隊。

但是困難不是退縮的理由。我們以明知山有虎，偏向虎山行的毅力開始了我們的外包資源池方案探索。

四、他山之石

關於外包資源池，MIG內部有應用寶走在前面。公司範圍內，IEG有不少的經驗。所以在我們開始設計我們的資源池方案之前，我們先了解了其他團隊的做法（一些關鍵詞）：

應用寶：代碼覆蓋率，SDK，iTest，強調外包公司的作用（包括資源池運作方案也是外包公司在出），按類型劃分任務，設立統一外包接口人。

IEG：ieg有一個itest平臺用於外包任務管理。該平臺對我們設計開發“外包任務和日報系統”有參考價值。

五、方案1：臨近小組資源池方案

方案描述：臨近資源池方案是指測試內容接近的2個項目之間組成臨近資源池。

方案提出思路：這個是在人力緊張的情況自然想到的一種方案。兩個項目的成員互相學習對方項目的技能，最終達到人力資源共用的效果。該方案分幾步走：

1）整理技能標籤並對任務和外包貼標籤；

2）小組內實現人力資源共用；

3）臨近小組實現人力資源共用；

4）整個瀏覽器測試組實現人力資源共用。

在想到這個方案的時候，我以爲我看到了成功的希望。

方案實施時間：2月5日- 3月31日。

失敗原因：前面2步都順利完成。進行到“臨近小組實現人力資源共用”的時候發現進展慢了下來。因爲臨近小組技能的互相學習是需要任務驅動的（通過做任務才能真正掌握技能），但適合放入資源池的任務太少（複雜任務不放入資源池）。臨近小組實現人力資源共用

目標遲遲未能達成。於是我們開始考慮新方案。

收穫和教訓：臨近資源池的準備階段，我們整理了外包技能集。這是一個囊個了外包測試需要用到的幾乎所有技能的培訓文檔。爲後面的工作打下了很好的基礎。

六、方案2：准入準出資源池方案

方案提出思路：既然任務少，我就拉任務，我把整個瀏覽器測試組想放進資源池的任務都拉進來；人少我就拉人，我把整個瀏覽器測試組能擠出來的人力都擠出來。只要我控制好任務和人，並且用技能標籤來做好任務和人之前的連接。資源池自然能運轉起來！

方案描述：該方案有3個要點：任務審覈、人員培訓和技能標籤關聯。

1、任務審覈：要通過任務審覈的任務類型才能放到資源池來。主要是確保任務足夠簡單以及給任務貼上技能標籤。

2、人員培訓：要通過人員培訓的外包才能進入資源池。主要是爲了保證外包具備基本的通用技能同時標記外包所掌握的技能標籤。

3、技能標籤關聯：通過技能標籤讓任務找到對應的人去執行。下圖展示了任務1和外包A是如何通過技能標籤匹配上的。

在想到這個方案的時候，我以爲看到了成功的希望。

方案實施時間：4月1日- 4月30日。

失敗原因：這個方案理論上是可行的，但實際操作性不高。一來做任務審覈、維護外包技能標籤比較繁瑣；二來在沒有系統支持的情況下通過技能標籤去配對任務和執行者不方便；最後是外包需要掌握的任務太多，第一次做任務效率低。測試經理也不放心。

收穫和教訓：過於複雜的流程規範註定無法落地生根，簡單纔是美。

七、方案3：項目帶頭人資源池方案

方案提出思路：既然任務太多，那我就只讓真正的簡單任務進來。第一次做任務效率低，我就找熟悉的人帶着幹！讓資源池先把最簡單的這部分任務接管起來。

方案描述：每個項目設立一個項目帶頭人。項目帶頭人對提到資源池的任務的質量和效率負責。爲了達到質量目標，項目帶頭人需要檢查普通成員的測試結果；爲了達到效率。

在想到這個方案的時候，我以爲我又看到了成功的希望。

方案實施時間：5月1日- 5月20日。

失敗原因：本方案解決是“真正的簡單任務”放入資源池的問題。而前面分析過，咱們瀏覽器測試組的其中一個特點是“任務難度大”。這個特點註定了我們組“真正的簡單任務”會很少。通過統計，深圳瀏覽器測試組“真正的簡單任務”只有4-5個人力，佔總任務量的20%左右。即使我們能將這部分任務的效率提高一倍，也就只能節省10%的人力，預期收益太少。因此本方案實施了半個月就被叫停。

收穫和教訓：投入產出比是我們做任何事情都需要考慮的問題。不能爲了資源池而資源池。