測試工程師的明天在哪里(2)

　　1.2.2 Engineer Productivity Developer

　　測試中會用到很多的工具和系統，如果組織夠大的話，通常為了效率和ROI，會把這一部分抽取出來給一個部門來做，我們稱之為engineering tools and service。其實這也是一條發展的路線，因為很多人喜歡去開發工具，讓更多人的從中收益。不過目前我個人的看法，這條路在一個不以測試工具為產品的組織里面會有瓶頸。畢竟國內純粹開發測試工具的廠商還很少，沒有像Spirent，IXIA, Micro Focus, 還有以前的Mercury之類的公司。

　　說到developer，很多人會說，轉到developer也是tester的一個 track。我不這樣以為，因為那樣而言測試不是一個獨立的工作，而只是developer的預科，在有些公司，特別是一些測試不正規的小公司，可能這種認識會比較普遍。但是這個不在我這里討論的范圍，因為前提是把測試做為一個獨立的工作類別。

　　1.2.3 Solution Architect

　　開發人員要一邊學習開發技術，比如編程語言，設計模式等等，另一方面要了解和熟悉產品相關的領域知識。比如設計和開發銀行的業務系統的人要了解銀行的業務。對于測試人員而言，同樣如此，甚至要了解更多。試想一樣，如果你去測銀行的利息計算的程序，你都搞不清楚利息計算的方式和銀行業的各種規章，又如何能判斷測試結果的對錯，被測系統設計得是否正確或者合理?換到別的行業和領域，也是一樣。長此以往，很多測試人員就慢慢成為了領域專家，對業務和產品都非常熟悉。這種熟悉和developer不一樣，通常developer是對某個他做的模塊細節實現有深入的了解，受限于時間和精力，無法了解產品功能的全貌，而QA的角色使得難以了解到代碼級別的實現細節，但是對于產品的各個功能，用戶的部署和使用場景等方面比較熟悉。于是乎就又了solution architect這樣的概念出來了，就是要針對具體的市場或者客戶過來的問題，能做評估和分析，給出相應的技術方案，并做技術的驗證。

　　我們公司現在有QA engineer在這種方向上走到和director同等的級別。這方面需要對產品的知識有非常深廣的積累。

　　1.2.4 Industry expert/leader

　　上面的三條路，你會發現其實是講平時的工作從幾個不同的角度去延伸，分別是深度，通用性和產品領域。其實還有一個延伸的角度，就是影響力的范圍，如果可以超出公司的范疇，可以超出行業的范疇，就變成我這里說的industry expert或者leader。這一方面，目前國內還不多，大家聽得多的還是國外的一些同行，比如James Bach, Alberto Savoia, James Whittaker, Scott Barber等等。

　　他們在很多公司工作過，不過大家記住和尊敬他們是因為他們做的演講，寫的書，提出的理論和方法，可以benefit到其他人，讓別人從中學到有用的東西。

　　這其實也是一條路線，獨立于公司和產品。但是這條路顯然不容易，至少要有深厚的積累，而且要有很強的歸納總結能力，能寫能講。當然很多這樣的人本身也在公司里面上班，也有一些是自己開辦自己的咨詢公司，比如James Bach。

　　好吧，和測試相關的談完了，下面我們來看看別的方面。

　　2、轉換到別的角色

　　2.1 項目經理，Project Manager，簡稱JM

　　測試人員，特別是QA Lead轉項目經理的例子在我身邊還不少。分析來看，有很多skill方面的東西是相通的，比如要做進度的管理，良好的協調和溝通能力，等產品的比較深的理解，對公司各種相關的部門和流程的熟悉。

　　2.2 產品經理，Product Manger, 簡稱PM

　　這種例子沒有上面多，但是也有一些。在我們的體系里面，PM負責整個產品roadmap的制訂，簡單來說就是決定下一版要做什么feature，以及對產品的市場定位和規劃，有一部分是偏向marketing的。相對于JM,可能更偏向于 business，對產品所在的行業，客戶，以及競爭對手有比較深入的了解。相對而言，跨度要更大一些，而且對個人性格特質的要求也不太一樣，因為JM畢竟還是屬于R&D的范疇，而PM不是。

　　2.3 售后和技術支持

　　這方面的例子也有，我前老板的老板就去做了support的director，不過這個好像還是偏管理的。engineer也是有的，不過這方面要看組織的結構是把support做為完全獨立的機構還是開發的一部分。

　　寫到這里，大部分都是我在工作中看到的例子，發現其實也不少。但是我深信這個列表一定是很局限的，一定有更多的。

原文轉自：http://www.uml.org.cn/Test/201106094.asp