產品測試組和業務測試組

本文討論的團隊模型，是基於阿里巴巴（淘寶、天貓）這樣比較複雜的電子商務互聯網公司；

本文討論的是軟件測試的團隊模型，開發團隊能夠參考，可是因爲開發和測試工做性質的不一樣，不能簡單的推理爲開發團隊模型；

Part1

通常電子商務網站，都有「會員、商品、店鋪、交易、評價」這些基本概念，在淘寶網最開始發展的幾年，這些產品概念在架構上是一個總體。隨着技術架構的發展，這些概念被一個接一個的從淘寶系統中拆分出來，造成一個又一個產品中心，以下圖（系統架構圖）：

底層的這些「中心」，都有獨立的測試團隊支持；而後接下來幾年，業務的發展很是快，除了淘寶網，又發展出天貓、聚划算、旅行等一些獨立的業務概念，以下圖：

上層這些組織，在阿里集團被稱爲Business Unit（業務單元，後面簡稱BU），每一個BU都會有獨立的測試團隊支持，咱們稱這些測試團隊爲「業務測試組」。底層產品中心測試團隊咱們稱爲「產品測試組」。這兩個概念只是用於本文討論，在真實的組織架構中可能並不叫這個名字。

在第一種架構的時期，並無什麼問題，業務測試組和產品測試組配合的很好，由於你們都是爲了同一個BU（淘寶網）在工做。但是當上層BU不斷增多的時候，矛盾就慢慢顯現出來了。

BU和產品中心產生了不少交集，好比「淘寶商品」、「天貓交易」這樣的，這些交集部分到底由哪一個測試組負責，這就是本文討論的主要問題。

Part2

因爲產品中心並不像物理層（數據庫、緩存）那樣抽象，也是具備至關的業務複雜度的，這就與BU產生了明顯的糾纏，因此交集部分的測試歸屬，就是一個你們沒法迴避的矛盾中心（這裏開發團隊也差很少）。另一方面，產品測試組原本是以支持淘寶BU爲主，當其餘BU如雨後春筍般增長的時候，產品測試組沒有及時進行角色的轉換，下意識的認爲本身的職責仍然是支持淘寶BU（主站），所以其餘BU的業務測試組，從產品測試組這裏能得到的支持要少得多，這也加重了矛盾。

關於這個問題的觀點主要有兩個，其實也很簡單。觀點1：交集部分由產品測試組負責，理由是產品測試組對產品中心結構很是熟悉，測試效率最高；觀點2：交集部分由業務測試組負責，理由是貼近業務和最終用戶，也能夠隨時響應BU開發團隊的測試需求。在很長一段時間裏，咱們常常聽到這兩種觀點的爭論，也一直沒得出特別靠譜的結論，有時還發展出第三種，也就是業務測試組和產品測試組「一塊兒負責」這種和稀泥的觀點，其實只是迴避了這個矛盾，並無從根本上緩解。

這裏咱們有必要簡單回顧一下產品測試組的發展過程，也就是從架構1向架構2的變化過程。當咱們仍是架構1的時候，產品測試組是按照觀點1的方式運做。當BU增多的時候，產品測試組開始出現人力資源瓶頸，不少BU的測試需求沒法及時的完成，因而出現了一種無序的，搶奪資源的局面。注意這只是現象，根本緣由是產品中心沒有站在全局的層面來進行人力資源預算和資源配置，而是任由各個BU爭奪資源。因而常常能看到產品經理處處圈人，測試經理疲於應付，卻也理不出頭緒。

因爲人力資源預算機制的缺失，「產品測試組缺人，是瓶頸」的觀點被你們逐漸接受了，甚至產品測試組本身也這麼認爲。可是更要命的狀況出現了，基於這個觀點你們開始繼續推理，既然產品測試組是瓶頸，那業務測試組就必須發展起來，承擔交集部分的測試工做。因而各個BU的業務測試組開始招兵買馬，團隊規模持續增長，而後慢慢接近於觀點2的工做模式。

雖然觀點2確實解決了BU面臨的測試資源不足的問題，可是觀點2是基於一個現實問題（產品測試組是資源瓶頸）進行推理，這樣的推理方式沒法根本解決問題。團隊模型的研究仍是應該從科學性出發，並且團隊模型的設定切忌走極端，不能由於在一個極端碰了幾個釘子，立刻全速奔另外一個極端絕塵而去，精力都耗在路上了。

讓產品測試組把全部BU的業務都搞定，確實不現實，可是若是把產品測試的工做，徹底拆散，而後分散到各個BU去，更加不靠譜。

由於觀點2的團隊模型的問題也很是明顯：

1. 多個業務測試組都是圍繞一個系統在測試，確定會存在重複勞動，資源利用率低；
2. 你們都只關注本身的業務，缺乏對產品中心全局質量的控制，可能會形成產品中心質量不斷惡化；
3. 產品測試組須要和n多業務測試組對接，不只費事，也極可能存在合做的空檔，形成質量風險

最後有必要分析一下那個「資源瓶頸」的問題，是否是真的存在，若是存在，是否是真的無可救藥。首先咱們作一個假設，X中心的產品測試組有3位測試工程師，要支撐3個BU，而後這3個BU都認爲測試需求沒法知足，因而把這3我的分別拆到這3個BU的業務測試組去工做，而後問題就解決了。真的是這樣麼？

即便在表象上看真的是這樣，這裏面其實還有不少隱情，我分析極可能是下面兩種狀況。A、這3我的在產品測試組，並非全力支持3個BU，可能只有一半資源在支持，另外一半他們去作「更重要的事情」去了，因而拆到業務測試組之後，資源加倍，問題解決；B、這3人來到業務測試組之後，仍然沒法支撐測試需求，因而測試經理給他們加了人手，增長到6人，資源加倍，搞定。

不少時候資源瓶頸並非由於人的總量不足，多半是因爲人力資源使用率較低，或者是人力資源計劃性不強。

Part3

分析了這麼多，這個問題是否是真的無解了呢？咱們仍是要回歸到BU的原始需求。若是產品測試組包攬一切測試工做，那麼那些業務爆發式增加的BU，確定會堅定反對，由於他們但願本身控制資源，由業務測試組快速搞定業務。另外一方面，那些業務比較平穩的BU，特別是跟產品中心交集已經很是穩定的BU，他們更情願把交集的測試工做交給產品測試組，不肯本身的業務測試組陷入一個他們並不熟悉的系統裏去，由於業務纔是根本，業務測試組應該更關注BU主營業務。

因而「BU業務發展速度」這個概念進入咱們的思考，看起來這個因素是形成目前矛盾的根源，但同時也是解決問題的關鍵所在。

不一樣類型的BU，支持的觀點也不一樣，有的BU支持觀點1，有的支持觀點2。咱們無論用哪一種方式，都會有BU不滿，是否是咱們須要考慮一種「混合」模式。在決定如何混合以前，咱們要把兩種觀點的優缺點分析清楚，咱們用下面的表格來對照，綠色字體表明優點，紅色字體表明劣勢；

測試工做	業務測試組	產品測試組
對BU業務熟悉程度	直接接觸業務方和客戶 隨時得到第一手資料	與業務方離得比較遠 瞭解業務不太及時
支持BU開發組的效率	與BU開發朝夕相處，溝通方便	交流不方便
對產品中心的測試效率	不清楚產品中心的結構 測試過程難以斷定真僞 對代碼的改動的質量風險很差斷定	對產品中心的架構和測試策略很是熟悉 測試效率高
產品中心質量總體控制	只關注BU自己的業務 對總體質量不關注	對產品中心的總體質量較好的控制
迴歸測試設計和管理	迴歸質量良莠不齊 重複腳本多，資源浪費 迴歸出現問題，確認超級費事 腳本統一設計結構清晰	迴歸覆蓋科學，管理成本低

 

從這個表格能夠看出，業務測試組的優點是快速的支撐BU的業務發展，而產品測試組的優點是對公共產品有持續的維護和完善。咱們能夠歸納成一句話：

業務測試組負責進攻，產品測試組負責防守。

這實際上是一種觀點1和觀點2並存的解決方案，BU的業務發展速度，是決定業務測試組和產品測試組分工方式的關鍵。不過只有這個概念仍是遠遠不夠，咱們須要進一步說明產品測試組的工做邏輯和工做內容，看看怎麼作才能更好的支撐BU，支持業務測試組的工做。

首先咱們要從新梳理一下產品測試組的工做方式，看看和之前有什麼不一樣。這裏須要特別引入前文重點提到的「人力資源預算」的概念，簡單來講就是，一個產品測試組能支持多少BU，一共須要多少人，這些人怎麼分配。目標就是讓每一個BU都滿意，注意並非給每一個BU平均分配資源，滿意是關鍵。咱們羅列一下產品測試組的工做重點（崗位描述）：

1. 一個產品測試組負責一個產品中心，但可能面對多個BU的開發組；
2. 一個產品測試組有1~2位測試leader，根據產品中心規模而定；
3. 明確哪些BU與本產品中心的交集，由產品測試組負責，哪些由業務測試組負責；
4. 對於肯定要支持的BU，產品測試組須要按期制定資源計劃，並獲得這些BU的承認；
5. 產品測試組負責設計開發所支持BU的自動化迴歸體系；
6. 產品測試組負責承接所支持BU的測試需求，可能改代碼的是BU的開發工程師，可是改的是產品中心的系統；
7. 若是所支持的BU在本產品中心出現故障，責任由產品測試組承擔；
8. 產品測試組要按期與業務測試組交流近一段時間的業務變化；

下面說一下上面第三點，產品測試組如何判斷應該支持哪些BU。前文說到一個「業務發展速度」的概念，這個概念比較抽象，咱們很難定義出，BU的發展速度到底有多快纔是邏輯區分點。這裏其實還有個更簡單的邏輯，那就是：

尊重BU研發團隊的意願。

在實際工做中，我接觸過不少BU的開發和測試，他們都但願由咱們產品測試組來完成測試工做，由於「大家對系統最熟悉」、「咱們人手也很緊」等等。既然客戶有這樣的需求，那咱們就把這部分工做接下來好了。若是BU堅持用本身的業務測試組，那也ok，產品測試組將不負責這個BU的質量。並且BU有足夠的自由選擇權，BU能夠選擇一部分產品中心的工做交給產品測試組，一部分由本身的業務測試組搞定，這樣也很是好，好比「商品管理我要本身測」、「交易流程大家去搞定好了」。

業務測試組和產品測試組的分工，不是一成不變的，而要根據BU的發展，動態的調整。

這一點也很是的重要，由於咱們討論的是一種混合團隊模型，變化將成爲常態，測試工做能夠在產品測試組和業務測試組之間轉移。舉例來講，好比某個BU須要對交易流程進行一個很大的改動，涉及到BU的核心業務，那麼就須要BU的業務測試組負責，產品測試組給予必定支持。等這個項目作完了，近一段時間BU的交易不會有大的變化（有些小修改），那麼就交給產品測試組來維護，業務測試組轉去作其餘的測試。也許過了半年，這個BU的交易又須要大的調整，那業務測試組再次出現，以此類推。

上面分析了這種新的團隊模型的優勢，下面也說說帶來的風險：

1. 常規的測試團隊模型，是測試嚴格對口開發，並按照固定比例配比（開發測試比），新團隊模型對此是很大的挑戰，不少人會不適應；
2. 產品測試組的人力資源仍然是風險，特別是當不少BU同時開始作「大項目」的時候，這就須要資源的預算要儘可能準確，資源調配也要更可操做；
3. 測試工做在業務測試組和產品測試組之間移交的時候，可能會產生問題，固然測試設計能力強，合做默契的團隊會好不少；
4. 因爲測試工做動態化，測試團隊的績效評估將面臨挑戰；

到這裏咱們的分析告一段落了，中心思想是要用發展的眼光看問題，不能形而上的但願用一種手段解決全部問題。本文所討論的觀點1和觀點2，都是對的，不用爭論哪一種更好。對於各個BU來講，天然會根據本身的業務特色選擇最合適的測試策略，做爲產品測試組須要尊重BU的選擇。對於測試工程師來講，那就問問本身究竟是屬於進攻型，仍是防守型。若是是進攻性選手，就加入業務測試組，享受跟業務一塊兒成長的成就感；要是防守型選手，就加入產品測試組，體會產品從80分到90分的進步，學習架構不斷完善的技術。