從技術角度看軟件測試工程師的分工模型(2)

　　從提交的bug質量上，很容易看出一位工程師的技術和能力，如果P6發現的bug，跟P4差不多，那怎么好意思繼續混下去。下面我們再從另一個維度來比較，那就是：是否專注在一個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人的測試團隊，我們按照足球隊的陣形，排出了測試人員比例模型，大家參考一下：

　　排下來感覺也挺靠譜的，才發現軟件測試和足球還有這么點聯系。當然，這只是常規團隊的排兵布陣，有一些特殊的project和產品線，是不太合適的，需要重新定義。不過要遵守這個原則，并不是層級越高的人越多越好，而是要各司其職，方能百戰不殆。

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