2010年底，技術研發部那轟轟烈烈的晉升面試慢慢落下帷幕，有人快樂有人失落。一晃幾個月過去了，晉升失敗的痛苦慢慢平復，晉升成功的快感也逐漸消退。接下來一個非常實際的問題擺在了我們面前，特別是對那些晉升成功的工程師來說，那就是，晉升成功後，你是不是依然做着相同的工作，跟以前沒啥分別。
儘管受到一些爭議，新的job model在這次晉升過程中，還是起到了比較關鍵的作用，它明確的定義了各個層級的測試工程師，應該具備何種能力，能夠完成哪些不同難度的工作。除此以外，我們幾乎隔一段時間就能看到一幅“測試工程師職業發展路線圖”，每張畫的都不一樣，不過中心思想基本差不多，無非是說測試是萬金油，可以向多個方向發展。
關於測試工程師的未來怎麼發展，似乎我們已經掌握了足夠多的信息了，按理說我們應該撥開迷霧，自信的大步往前走。但是我們卻感覺到哪裏有點不對勁，並沒有體驗到輕鬆暢快的感覺，相反，仍然覺得身在迷宮深處。這些並不正常，我想技術委員會應該做一次回訪，針對晉升成功的測試工程師，問問他們的感受，是否感到個人價值倍增，信心百倍，目標明確。
下面只是我的推測，我想回訪的結果可能不會那麼好，並且很可能會得到相反的答案。雖然晉升成功的感覺很high，薪水也高了，還有同事們那羨慕的眼神，不過這些快樂都是極其短暫的。當大家冷靜下來，回到工作崗位時，晉升成功的工程師會發現一個尷尬的現實：他們仍在做着跟以前相同的工作，並沒有得到組織授權的，完全不同的任務挑戰，也沒有新任務委派的動向，一切都那麼平靜。再看看周圍，他們發現了一個更加要命的問題，層級不同的測試工程師，卻在做着相似的測試工作。P6在帶個項目，P5也在帶項目，甚至P4也在帶個小項目。
其實真要說區別呢，也不是沒有，他們帶的項目還是有不同，有的大，有的小，但是看看項目中的具體工作，區別就不是很大了，都要寫計劃，寫一堆用例，一遍一遍的執行，記錄一堆bug。這種分工方式看起來合理，責任明確，各管一攤，其實不然，這種分配方法是最簡單的，但是很不科學。因爲大家都知道，在一個項目的測試工作中，總有一些工作是很簡單並且量很大的，而有一些是很複雜但是量卻不多，二八原則吧。P6工程師會覺得做那些簡單的工作很無趣，而P4工程師會覺得做那些複雜的工作很吃力很累。
我認爲這一點，是造成測試工程師對職業發展產生迷惘感覺的最主要原因。P4、P5、P6...每個層級都應該是一個里程碑，當你到達這個里程碑時，將會在各方面有一個很大的突破，而絕對不是周而復始的，不停的在做項目，然後熬很多年，熬成一個組的組長，然後每天處理一堆雜事，最終迷失自我。這絕對不是我們該走的路。
上學時學過，人類進化的一個關鍵，是社會大分工，每個組織負責不同類型的工作，精益求精，不斷進化。測試工程師的工作如何分工，和job model產生了必然的聯繫。job model需要完成3個層次的定義：1、各層級測試工程師的能力定義。這個已經完成了，這裏我們不再多說;2、各層級測試工程師需要完成哪些類型的工作。這個其實現在的model並沒有說清楚，所以大家在工作中會感覺到有些迷惑，不過根據現有的job model倒是可以推理出來，後面我會總結一下;3、一個健康的測試團隊，各個層級的測試工程師的比例。這個完全沒有定義，所以我們馬上會重點分析。
先講第二點。真正合理的測試工程師分工，我想應該不是P5負責A項目，P6負責B項目，也不是在一個項目裏，你負責甲模塊，我負責乙模塊，當然更不能是，測試負責人把模塊平均分給幾個人，然後自己負責所謂“溝通協調”的工作。不同層級的測試工程師，他們的分工應該按照工作類型來分。我們看下面的表格：
|
測試工程師層級 |
負責工作內容 |
|
P4 |
1.根據需求文檔和測試文檔掌握測試策略 2.執行大部分的較簡單的TC 3.記錄bug 4.完成project的簡單日常測試 |
|
P5＝PTM |
1.制定project測試計劃 2.完成所有TC的設計，包括設計測試準備工作方案 3.執行project中較複雜、較核心的TC 4.記錄bug，控制bug健康度 5.爲project編寫知識沉澱和培訓文檔，方便P4工程師快速上手 6.對project質量薄弱點進行控制，減少線上bug數量 |
|
P6 |
1.根據project業務特點和架構特點，設計更科學的測試策略 2.幫助PTM提高測試效率（多方面的） 3.解決project中特別棘手的技術問題 |
|
P7 |
1.工作內容與P6幾乎一樣 2.解決問題的方式必須更科學，適用更多project 3.需要聯合開發團隊和其他測試團隊共同處理問題 |
這裏我們明確一個概念，就是項目(Project)，在新twork中，項目的概念變大了，購物車、收藏夾這些都是項目，而購物車2.0、收藏夾3.0這些是演進的一些版本。因此，PTM(Project Test Manager)有了新的含義，其實就是之前所說的“子產品的owner”，但是這樣叫太拗口，乾脆以後統一叫PTM。注意，P4工程師的責任範圍內，是沒有PTM的責任的。
好，下面我們繼續講不同層級的分工。上面從工作內容上進行了分類，下面我們從他們所提交的bug，來進行一下分類，請看錶格：
|
測試工程師層級 |
發現的bug |
|
開發工程師 |
80％初級bug 初級bug只要開發簡單自測一下，就可以發現，如果由測試發現，記錄、修復、驗證、溝通，極大浪費了項目人力資源 |
|
P4 |
20％初級bug 80％中級bug P4工程師覆蓋的測試用例，都是邏輯清晰明瞭的，比較容易判定的，因此發現的bug，大部分是中級bug |
|
P5＝PTM |
20％中級bug高級bug PTM需要覆蓋project中最複雜的邏輯，並且要花很多時間進行探索性測試，因此發現的bug，大部分是高級bug |
|
P6 |
你們自己看着辦 |
|
P7 |
你們自己看着辦 |
從提交的bug質量上，很容易看出一位工程師的技術和能力，如果P6發現的bug，跟P4差不多，那怎麼好意思繼續混下去。下面我們再從另一個維度來比較，那就是：是否專注在一個project裏面，請看錶格：
|
測試工程師層級 |
對Project專注程度 |
|
P4 |
可以在幾個Project中輪迴 |
|
P5＝PTM |
必須堅守自己的Project |
|
P6 |
可以選擇堅守一個Project，也可以不限定Project |
|
P7 |
完全不限定Project |
講到這裏第二點“測試工程師的分工”就講完了。P4工程師的考評最簡單最好量化，他只要按照文檔，完成一定功能點分數的測試，就可以了。在執行過程中，P4也不需要大傷腦筋，如果有壓力也是工作量的壓力。假如P4工程師感到執行測試很困難，舉步爲艱，那說明PTM的設計和準備，沒有做到位。而P5P6工程師，雖然擺脫了大量機械的工作，感到無比暢快，但是很快就會感到一絲不安，因爲他們有了更多的資源，因此會受到了更大的壓力，這種壓力主要是思想上的壓力，不過這些都是正常的，也是合理的。
我想一定會有很多人會對這種分工方式產生疑問，那麼這裏我先預測一些問題，跟大家解釋一下。
Q：如果一個project的用例都由PTM寫，ta能忙得過來麼?
A：這就要看用例的規模了，如果按照現在我們的寫法，估計夠嗆，用例寫成“說明書”，PTM肯定累半死。用例應該是一個結構化的文檔，與知識沉澱珠聯璧合，總之這就要看PTM的能力了，怎麼設計才能既簡潔，又可讀。另外如果項目太大(不禁想起WCS)，那估計要多位PTM合作。
Q：PTM把用例寫好，那執行第一輪測試的時候，他不是沒事幹了。
A：這是因爲以前的規定是，用例全部寫完，評審完，才能測試，這樣其實是不敏捷的，用例的設計和執行本身就可以並行來做，評審只要把關鍵的測試邏輯評審通過就可以了。開發工程師也是希望我們儘快投入測試，儘快提交bug。另外，測試開始後，PTM還需要不斷完善測試方案，特別是測試數據準備方法，PTM要爲P4的工作鋪平道路，絕對不是甩手掌櫃。
Q：這樣定義，對現有的P4工程師，是不是會感覺不好，好像在說他們只能做簡單的執行似的?
A：說到這個問題，還請大家保持冷靜。對崗位的定義，和對人的要求，是完全不同的，要區別對待。我們設定P4這個崗位，說明團隊需要這樣的崗位產出，絕對不是說現在這個崗位的工程師只能做這些。對這個崗位感興趣，適合的人，自然會接受崗位offer。當ta在這個崗位上有了較好的績效，經常會涉及更高層級的工作時，那麼就可以自然晉升了。
到這裏第二點我們分析完了，下面講第三點：健康的測試團隊中，各個層級的測試工程師比例應該是怎麼樣的。
現在我們的招聘策略是儘量挑選精英工程師，簡單來說是至少P6級別，這是非常正確的方針。如果一個團隊全是P4P5，在測試技術發展上，必然會遇到難以逾越的鴻溝。那麼是不是P6越多越好呢，也未必，試想一個產品線測試團隊都是P6，是什麼情景。在籃球論壇有人提出這麼一個觀點，如果由5個科比組成的籃球隊，可能戰勝不了大聯盟的任何一支球隊。雖然沒辦法證明，我認爲還是有些道理的。足球隊最出風頭的是前鋒，要是11個都是前鋒，也沒法踢了。推理到測試團隊也是一樣，大家自己體會。
說到這裏想起三國殺遊戲，裏面分了主公、忠臣、反賊、內奸幾個角色，在多人遊戲中，這些角色的數量是嚴格定義的，只有這樣設定，各方面勢力才能均衡，纔好玩，忠臣太多反賊太少，一下就結束了，一點不好玩。並且，當遊戲人數發生改變的時候，這些角色的數量也會跟着變，還要遵守一定的規則，保持生態平衡。
測試團隊也是一個生態圈，各方面勢力均衡，工作纔好做下去。其實一直以來，“開發測試比”就是開發團隊和測試團隊保持生態平衡的一個重要指標，這個指標也是討論最多，大家關注最多的。我認爲每個測試團隊，也需要確定自己的人員比例，可以根據所對應的Project的特點進行調整。下面假定有一個10人的測試團隊，我們按照足球隊的陣形，排出了測試人員比例模型，大家參考一下：
|
比例模型 |
不同層級的人數 |
|
5-3-2 |
5*P4 3*P5 2*P6 |
|
4-4-2 |
4*P4 4*P5 2*P6 |
|
4-2-3-1 |
4*P4 3*P5 2*P6 1*P7 |
排下來感覺也挺靠譜的，才發現軟件測試和足球還有這麼點聯繫。當然，這只是常規團隊的排兵佈陣，有一些特殊的project和產品線，是不太合適的，需要重新定義。不過要遵守這個原則，並不是層級越高的人越多越好，而是要各司其職，方能百戰不殆。
希望這篇文章，能夠幫助大家理清思路，從職業發展的迷霧中走出來，也希望能以這篇文章作爲引子，與各位測試經理們繼續討論測試團隊的建設模式。最後總結一句話，我希望測試團隊向着生態平衡，良性循環的方向前進。