测试工程师的明天在哪里(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