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

　　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項目，也不是在一個項目里，你負責甲模塊，我負責乙模塊，當然更不能是，測試負責人把模塊平均分給幾個人，然后自己負責所謂“溝通協調”的工作。不同層級的測試工程師，他們的分工應該按照工作類型來分。我們看下面的表格：

　　這里我們明確一個概念，就是項目(Project)，在新twork中，項目的概念變大了，購物車、收藏夾這些都是項目，而購物車2.0、收藏夾3.0這些是演進的一些版本。因此，PTM(Project Test Manager)有了新的含義，其實就是之前所說的“子產品的owner”，但是這樣叫太拗口，干脆以后統一叫PTM。注意，P4工程師的責任范圍內，是沒有PTM的責任的。

　　好，下面我們繼續講不同層級的分工。上面從工作內容上進行了分類，下面我們從他們所提交的bug，來進行一下分類，請看表格：

原文轉自：http://www.kjueaiud.com