规划好你的测试工程师之路

　　如果一个人很认真的看待自己的工作，那么可能会常常想到发展的问题，所谓人无远虑，必有近忧嘛。同样的，测试人员也会常常问发展的方向在哪里，这其中，刚入行，准备入行或者做了几年的恐怕都有。

　　为讨论方便，我把我看到的发展道路分了两大类，测试相关领域和非测试直接相关的。

　　1.先说继续留在测试领域的。

　　1.1 再细分，第一类是管理路线。学而优则士也是有传统的，所以并不奇怪。

　　这一路线的发现大概是QA lead à QA manager (QM) à QA director

　　各公司叫法不同，大概的意思如此。一般是先开始做测试团队的lead，或者叫组长。严格意义上，这个还不算是管理的职位，但是也算是预备。不过实际中，做lead并不一定意味着要发展到manager，很多技术路线的也可能在一段时间担任lead。其中的一个原因是做lead是非常锻炼人的，即便以后走技术路线很多的知识和技能还是必备的，也是相通的，比如协调的能力，沟通的能力，对全局的把握。

　　我个人的观察，不同的group可能风格不同，或者取决于QM管的范围，有些项目，QM介入很多，有的则很少，所以相应的lead的职责和空间也不同。

　　如果是管理路线，到后面是QM了，当然也可能会有acting(实习)的阶段。到QM后是比较纯粹的管理路线了。当然，看个人的风格，有些QM也是比较technical的，也会经常研究测试工具技术和方法，并出去分享。但是职能上讲，很多一部分工作是team的建设管理和人员的选择培养，按照我们公司的划分，是属于people manager的范围了。

　　再往高处，是QA Director，比如在blog上活跃的Kerry老师，下面带一些manager，产品的范围也更大，有些可能不看具体的项目了，而更多思考一些全局性的方法和策略，但是人员的培养应该也还是主责。

　　看公司的大小，也可能会有更多的层级，不过大致是一样的。在这条路上，到某个时候，再往上，可能越界了，意思是不再直接和测试相关了，比如升任研发总监或者VP，到这个层面，已经不分开发和测试，因为两边的report line汇总到一个人上面了。我们公司三大RD head中有一个做了很多年测试，有次和他吃饭聊起这个话题，他说早期公司人少，全职的测试人员也少，所以有机会接触很多不同的产品，也得益于此。

　　1.2 技术路线

　　这个想必大家也不陌生，国内很多的公司，特别是稍大的公司都在提。其中有一个很直接的原因，那是上面的管理路线会很依赖于组织结构和组织的成长，通俗的说是要有坑才行。另一个方面，产品的精深对于高层次的技术人员也有更多的需求，而且不是所有人都想或者都适合走管理路线。那么对应的技术路线也很自然的出来了。其实关于这一部分，近几年我们的讨论也很多，一度大家也很迷茫，一个简单的问题是，大家没有想明白一个和manager，甚至director拿一样薪水的QA engineer应该是什么样的，有什么样的能力和贡献?

　　现在我们有了一些思路。这里说的是我个人的一些看法，不是官方的定义。

　　1.2.1 Domain Expertise

　　第一类是测试领域的专家，这一类Jack在文章中也有讨论。比如说automation，performance，security，compatibility等等领域，都是需要长久的积累，也很有专业性，可以产生对应的领域的专家。这样的专家也是从产品和项目中锻炼出来的，但是慢慢的发现，他们的经验和技能越来越深，而且也变得更加通用，可以让其他产品和项目也收益，这种影响力甚至可以扩展到其他部门，有点横向的发展。

　　关于这条该怎么去走，这里不展开了，姑且先知道有这么条路，应该有很多值得讨论的。

　　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这样的概念出来了，是要针对具体的市场或者客户过来的问题，能做评估和分析，给出相应的技术方案，并做技术的验证。