【转】测试？资深？管理？你伤不起！！！

http://www.51testing.com/?uid-68857-action-viewspace-itemid-236965

话说我们测试部门巅峰时期曾经有150多人，后来由于集团业务发展，测试部门分成了两个，我们部门保有110人左右，另一个测试部门约有70多 人吧。新生的部门我不了解，单看我所在的这个庞大的测试部门，我这两年来（除了今年，今年笔者不吱声了）一直不断地诟病方方面面的问题，向领导反馈但由于 没有给出实际解决方案而最终无法“上达天听”，最后也就变成了敢怒不屑言，现在索性写出来给自己、给大家看看吧，或许从字面上能发现一些解决的途径。

整体层次感模糊

说到资深测试工程师这个头衔，我觉得更多的不是体现技术能力和头脑的灵活，而是工作经验、综合能力和资历，在公司内部有一定的人脉，有着与干系人较多的合作经验。当然，不同的公司依据自身的体制对测试人员的称呼也有所不同，我们这里不去纠结这个。我们公司是采用职级制度，初级测试工程师的可能就是指本科毕业3年以内的同事，也就是在工作2年后由初级升到资深，当然这两年的考核要在一定的百分比之内。那么由初级升到资深看起来是件很简单的事情了，或许正是因为这个资深的头衔来的太过简单吧，我们的整个测试部门没有综合能力上的层次感，有些工作3年或者5年的同事与工作2年 之内的同事在各个方面没有多大差别。另一方面，在日常工作中领导并没有把测试分析、测试设计、和测试执行在资深测试工程师和初级测试工程师之间进行明确的 分工，往往由某一个人全程负责测试分析、设计和执行。虽然我们尝试过使用测试执行工程师（执行员），但是沟通成本太高几乎让所有的测试工程师都抱怨不休； 另外，对测试执行员没有有效的培养和激励机制，而且领导决定原则上只招收大专毕业生（摆明了就是学历歧视），导致他们本身工作也没有多大积极性，这个划分 体系也就渐趋式微了。

针 对这种情况，我认为应该从职责和职位上进行细化分解，把测试工作逐层分离，这样对于测试部门这样的成本中心来说，人员流失就是不很大的问题了。因为依据能 力合理分解工作，职责分明，进一步铲除吃大锅饭的意识，让能力更强的人承担更加有价值的工作，也能吸引更多人才，而不会让这些真正的“能人”的出走带动连 锁效应，造成很大的人员损失，因为这些能力更强的测试人员的非职权影响力也是不可小视的；我亲见过（在我上一家公司）一个牛人辞职陆续带走一群人的情况。 具体如何分层划分测试部门的职责和职位呢，具体情况具体对待，我觉得大致可以参考如下结构，由上级领导进行技术和综合能力的考评，而不使用资历评判：

Ø 测试部门经理、测试总监、质量总监——负责管理整个测试部门的人力资源；

Ø 分组测试经理——适合20人以上的测试部门，因为每个团队最佳配置应该是8、9个人；

Ø 技术主管/测试架构师——每个分组配备一位技术主管或者测试架构师；

Ø 高级测试工程师——通常5年以上经验而且达到一定技术层次；

Ø 中级测试工程师——通常3年以上经验并且满足一定技术层次；

Ø 初级测试工程师——通常是应届毕业初几年，刚开始工作的同事。

作为一个测试主管，如果你让大家所从事的工作内容都基本一致，而你却跟别人说资深测试工程师的一个人月的成本是15万，初级测试工程师的成本是9万5，你这不是自欺欺人么？除了资深测试工程师的工资比初级测试工程师的高一些还有什么差别呢？另外，既然工作内容一样，凭什么资深的要比非资深的工资高呢？

当然，或许你会回答说资深测试工程师业务知识熟悉得多，那么我们来看看包含业务知识在内的各个方面的综合能力发展情况吧。

综合能力不健全

既然是软件测试，那么测试人员至少应该具备三个能力：业务知识、IT专业技能、职业技能。一般情况下，对于资深测试工程师来说，由于长期在一个公司或者一个行业工作（喜欢换行的咱们不讨论），他们的业务知识一般的确比初级测试工程师熟悉很多。

而他们优势最明显的是职业技能，职业技能对测试来说较多的体现在沟通能力、协调能力上。但是，在我们公司，这个词并不见得代表一种正面的解释，是因为有部分人把 这种能力变成了扯皮、推诿的能力！尤其在一个部门非常多的公司，长期的跨部门协作练就了他们敏感的神经和打哈哈神功：不轻易明确自己所代表的测试部门的立 场，不发表与多数人意见相悖的言论，哪怕自己有十足的把握大家的看法是有疏忽或者片面的，自我保护意识很强……甚至有些人根本不认为自己有权利和义务去否 决有严重问题的版本的下发！十分崇尚升级，事无巨细，只要自己没有经历过的便推到领导那里，即便自己有权利和能力去分析决断。看起来是一个十分没有个性、 十分听话的员工或者团队，如果本职工作进行得不错，那么领导是十分喜欢的，因为他们从不“捣乱”。相反，也有一部分人喜欢“倒江湖”，相信自己能够代表所 有人，很豪爽，喜欢随意许诺，有时候犯的错误会让领导“恨得牙直痒痒”。相比之下，初级测试工程师由于大都刚从校园出来，显得稚嫩而直率的多，虽然错误不 会少犯，但是如果善加诱导，他们的进步会让人看在眼里、喜在心里。如何能够让他们避免过多接触“扯皮神功”和“倒江湖神功”就要看公司的体制了。就我们公 司来看，如果没有重大变革发生，大部分应届毕业生将会延续前辈们的旅程，可惜我也只是动动嘴皮子，未必能提供什么有建设性的意见，但愿英明的领导们能洞察 这些细节，不要让这种怪圈循环持续下去了。

在IT专业技能上，有两种发展趋势：一种是随着经验越多技术越强、大局意识越强；另外一种是被温水煮的青蛙，慢慢的失去跳跃的能力，那么等着被开水烫死，要么跳出去……由于温差太大而被冻死。很悲剧的是我周围有大半的测试同事走向了第二条道路，可能随着年龄的增长，学习和接受新知识的能力在下降吧，我们很多资深的老同事对新技术、新方法持怀疑、观望甚至抵触的态度。这样一来整个测试部门的情绪看起来并不那么高，学习氛围不是很好，整体技术水平不高，而且断层明显。比如在我们部门，且不讨论测试分析设计本身的能力，了解QTP的可能有90人，但是精通的不过2、3人，其余的只停留在简单的录制、修改的层次；了解Selenium的20来人，精通的可能仅1、2人甚至没有；了解Oracle和SQL的100多人，懂得优化算法和SQL效率优化的也不过3、5人；了解性能测试的大约50人，精通它的2、3人而已，还有中间件、操作系统……而且我发现，就是那么几个人对各种技术都有涉猎，而其余的同事则似乎是没有强压根本不会去学习，遑论深入研究了。我分析造成这种局面的原因有这么几点：

Ø 价 值取向或者说兴趣不在技术本身，对于偏资深的测试工程师来说，大部分可能都已经成家，他们不愿意挤出时间在技术研究学习上，而更乐于回去照顾宝宝。我曾经 尝试举办很多次技术分享和请外援来进行技术培训，但是大家都报着拿培训积分的态度去参加，培训完毕立刻就忘记了，根本不去主动尝试研究和应用。这一点基本 无法改变，除非有足够多的利益放在他们面前，但是这这种诱惑也会养成娇纵的情绪，是不可取的。

Ø 公司运作方式决定了大家的工作很忙碌，一个测试人员要应对10来个开发人员的代码，压力大貌似很锻炼人，但是只是锻炼我们时间管理和处理并行任务的能力，并没有给我们留下多少学习的空间。而且在这种情况下工作，即便有朝一日清闲下来，很多人也不再愿意学习了：人的能力就像弹簧，拉直了就再也缩不回去了！

Ø 有些领导信奉这么一个观点：公司付薪水是让你们工作的而不是学习的云云……对这种说法吾深鄙视之！殊不知所谓的学习不仅是对个人的提升，也是在为公司提高产能。如果整个测试部门在使用QTP作为UI测试的工具，那么就不能留出一些时间让对Selenium很有兴趣的同事去研究一下Selenium么？假如有朝一日需要这么一种工具或框架的支持，谁能担当此任呢？

Ø 测试部门的培训机制不健全，偶尔有培训的机会，便进行大规模的“推广培训”，没有提供有效的技术深入探讨和学习的机会，例如参加测试沙龙、举办技术交流会议，或者搭建知识共享体系，仅有的一个Wiki到如今我也不知道自己的用户名和密码是啥。负责培训的人好像只是为了花完这笔培训预算而进行培训，根本不在乎大家整体的知识层次是怎样的，也就不去仔细的调查分析。如果不分析就提供几门看似华丽但是毫无用处的课程让大家自己去选，还要这个负责人有什么用呢？

这 样看来，随着我们的“资”变得越来越深，我们的综合能力好像并没有得到质的提升，所谓的资深测试工程师，好像除了业务知识并没有什么优势了。相反初级测试 工程师看起来则更有学习的欲望，更容易管理。人说职业发展要经历：有冲劲期、疲惫麻木期，之后再回到有干劲的状态，这种理论在我们这基本属于扯淡，因为我 们的测试人员看起来只要一旦疲惫就必定会辞职……恢复有干劲的状态那是在别处的事情了，我们这是看不着了吧。

工作效率与方法

本 来不想说这档子事情的，显得自己没气量，不过既然是分享，那就把细节都告诉大家，这样大家替笔者分析的时候就不会漏过细节了……我也承认自己心胸的确不够 宽广，要不然也不会蛋疼于我所看到的种种情况了。大部分公司都有个“优秀员工”的表彰的吧，我们公司也有。其实在笔者心目中，这个称号很值钱，自己不敢轻 易去想的，尤其是我刚入司第二年见到我一个很强的师兄获得这个殊荣之后。这位师兄是运维人员，他为我们公司开发了运营监控平台，改变了应用系统每晚要人值 守的循例。在我看来，他的JAVA编码强过一般的开发部门的编码人员；数据库与一般DBA水平相当甚至更高一些；对中间件的熟知程度赶得上了大部分基础架构专业中间件管理人员。在得知这么一位牛人存在之后，我就一直不停的向他请教和学习，而且他也很耐心，所以我觉得他被称为“优秀员工”是必须的，而且别的“优秀员工”也应该如此。

但是今年的公告却让我改变了一些看法，我们测试部门的一位同事竟然也获得了这个殊荣，不过这位同事并不是我想象中的那么优秀。粗略估算，他负责的关键系统全年发布了约20个版本左右，几乎每个版本的发布前一天他都加班到深夜，而且基本都是和开发、部署、中间件、DBA一 起定位处理一些问题。但是，几乎每一次都被证明是测试环境数据或者配置问题，虽然开发不停的抱怨为何不早点发现问题或者为啥总是环境有问题，但是他们还是 得陪着解决问题。每个月的加班记录表中总会有几笔他的记录，而且基本都是在临近版本发布的时候，而单就加班这一件事情来说，可能领导看到的是他很认真负责 的跟踪每一个发现的问题吧，那么如果别人不会把问题留在最后才发现就拿不到“优秀员工”的称号？其实这只是很小的一个例子，笔者虽然有点羡慕嫉妒恨，但其 实也只是想借此表明工作方法和效率是很重要的；我们再看一些其他的很有代表性的例子：

Ø 经常在爬在别人工位上一起讨论问题的时候发现有些人的邮箱里总有几百上千封的未读邮件，请问您能保证这其中没有急需您来配合处理的事情么？

Ø 经常有人来问我：上次你说那XXX是怎么回事来着，我记不得了，我回答说自己找邮件呗，我都整理了总结文档发给大家了啊；答曰：邮箱太乱，找不到……拜托，Outlook是可以设置规则的好不？

Ø 经常有人为了自动化测试的指标达成情况找我来做数据采集，其实就是到QC数据库里面查一些数据而已，我就很纳闷为什么大家不能保存一下我发给你们的数据采集脚本呢？

Ø 经常侧耳听到有人在和UAT人员沟通时说：等一下，我帮你找一下测试环境的地址……哎，这些地址太多了，再等一会哈……我就没明白，为什么不能在IE上设置链接分类来快捷打开呢，难道这些工作只做一次，下次无需再进行了么？

Ø 经常见到为芝麻大点小事组织多方会议，但是会议很快就进入了大家各自发牢骚的议程，没有结论，然后回去继续邮件沟通，N个人用N*N封邮件来解决一件事情，这……值得么？

Ø 经常……

工 作压力大没错，但是我们很多同事却忽略了造成我们工作压力大的一方面原因是我们自身的工作效率是可改善的。如果在日常工作中注重一些细节的效率提升和方法 的改进，那么我们的境遇或许不会像目前这么悲惨了。因为领导只要不是爱心泛滥或者是个笨蛋，他们都能看得到大家工作量上的差别，他们不会一直认为相同工作 量的情况下你的加班是额外的付出，时间长了他们会认为你无论做任何事情都需要加班，那是因为你做事情喜欢拖沓，原本就不值得同情！

这 点对资历较老的同事来说显得更加重要，因为长期的工作很容易让人形成习惯和思维定势，处理问题的手法千篇一律、毫无新意，而且对于工作时间较长的同事来 说，改变这种习惯所需要付出的代价会比刚毕业的新员工大很多。就像中学时做几何证明题，一道合理的辅助线比一道一般的辅助线对这道题目来说作用是不一样 的。虽然方法都是对的，但是合理的“投机取巧”让我们能够省出更多的时间来处理其他的问题。我们现在的情况是，至上而下，从没有人去关注这些细节，也不会 从理论上去推算这对我们的工作有什么影响。只是一味鼓吹自己的管理技术多么强大，要求员工按照自己定制的规范与流程去工作是毫无意义的，管理者只有通过指 导或者组织交流等行为来影响或者改变部属的行为，从而达到提升工作效率的效果才是王道。那么我们是否都能够把自己的管理工作做好呢，笔者这里冒死来批判一 下我们的有些主管和准主管的行为吧。

做管理你称职么

对于大领导来说，最悲剧的行为是喜欢“搞运动”，但是又收不到预期的效果。在分析原因的时候我们会发现，BOSS的想法没错，小弟们按照得到的指示去操作也没错，那么错在哪里呢？基层主管！对于我们测试来说，发展自动化测试是没有什么争议的事情，提高测试分析、设计能力以达到更好的测试效果也是没有争议的事情。笔者就以此两个例子来分析一下，我们的运动为什么没有达到预期的效果呢？

首先说第一个：自动化测试发展建设，我们07年开始进行自动化测试建设，引入QTP这种工具，而在此之前笔者已经有一年的QTP使用经验了。奇怪的是，没有任何征兆，指标直接下达，要求半年之内所有关键系统自动化覆盖率70%，大家知道这意味着什么么？100个没有使用过自动化测试工具/QTP的测试人员要在半年内完成大约10000个自动化测试脚本的编写。须知我们当时每半个月就有一个版本要发布到生产，有些系统频率可能会更高，每天能挤出半小时时间就已经相当不容易了，何来精力去做这些压根就毫无根基的事情呢。后来才得知是一群测试分组经理坐在一起“研究”了一把，觉得QTP录制起来很快，每人每天搞几十个应该不成问题……我勒个去哦！宋峰宋老师有篇文章说“六拍”说得很好，而且我觉得说得就是当时这种场景，不过这是由一群基层主管替领导拍胸脯，为下属拍脑袋！结果我不说大家也能猜得到，我们达成了指标，更精彩的是，在接下来两年里面，我们的QTP脚本被废弃、重新开发再废弃再重新开发好几次！拿周立波的话来说：啊——爽滑到底！

这个例子说明了什么？做IT管理首先得懂技术，不了解细节和深入的问题就不要轻易拍脑袋，要仔细调研分析，征求多方意见，观察行业动态等等，总之要先做足了功课。否则的话，跟您这一比，“酒驾”啊、超速啊神马的压根都不算个事，人家那害不了几个人，您这害了很多人——几乎就是半辈子！

再一个就是我本人引发的（至少我自己一厢情愿的认为和我有关吧）血案，系统功能点和测试分支的整理，不知诸位听说过没有，事情的发展还是远远超出了我的预期的。08年9月 我在西安休年假，领导就最近的几个测试遗漏问题咨询开发和一些测试同事，看有没有什么好的办法能够规避这种问题的产生。休假嘛，骨头痒痒，就洋洋洒洒写了 几百字回去，主要意思就是要把测试分析做到位，把测试部门的职能细化，不能由一个人从头到脚的去照顾一个系统的需求。可能领导觉得这种说法挺有道理，后来 又去咨询了一些砖家叫兽吧，最终在09年初把这个想法汇报给了新任部门经理。在层层决断之后，由我们公司的总助拍板说，好，这件事情是有意义的，你们做吧，给个明确的计划，并且把这项工作列入KPI之一，用于考核测试人员的工作成果，这件事情由XXX负责统筹吧。然后XXX组长创造性地把这个十分抽象的工作实例化了，经过几次PK未果之后，我放弃了反抗，眼睁睁的看着这项运动如火如荼的展开了。这位负责人如何实例化这项工作的呢？她要求所有测试分组，把代码的分支罗列出来，分配到不同的功能点下，记录在QC中，进行详细的说明；后续做了很多的QC二次开发，做的页面逻辑控制让人一开始做测试需求录入便有要死的感觉。要知道我负责的是个中型系统，它的package代码就有几十万行，掺杂着JAVA无 比强大的页面、组件复用，厘清分支谈何容易呢。按照惯例，在几个月之内完成，我们都完成了，至于后面所花费的时间真的很让人心疼，尤其是这件事情本身为后 续的测试需求分析、录入工作带来了很大的不便。那么起到什么效果了呢？我还真不清楚，也没有人敢在年度报告上提这项工作的量化成果，只是会提到我们的功能 点、分支的回归测试覆盖率达到了多少，至于功能点、分支分析的全不全就无人问津了。我不知道这个事情责任到底是不是在我，若真的如我自作多情所猜想的一 样，是因为我的言论诱发了这件事情的话，我真的会有想砍掉自己指头的冲动；若不是呢，那我可以坦然一些，至少面对同事们的时候不会为此而羞愤，而即便是这 样，我也还是为自己没勇气越级诉求扭转这项工作的方向而惭愧。

这件事情自上而下看起来都合情合理，问题就出在执行上，可能所有人的初衷都是一样的：那就是改善系统测试的质量，降低生产缺陷量。但是在执行的时候，这位负责人并没有去分析这件事情本身所带来的负面效应，也没有真正理解问题提出者的意思：加强系统测试需求分析，分解测试过程。她一厢情愿的认为加强测试需求分析就是把测试人员对需求的理解录入到QC指定的目录下，以证明测试人员对这个需求的理解是正确的；把测试需求分析和测试用例分开管理就可以达到测试过程分解的效果。谁知道对需求理解正确就一定会没有问题出现呢？关联影响和深埋在应用系统中的历史遗留缺陷如何分析出来呢？其实这件事情做与不做都能达到对新功能测试的 质量保证，领导的核心需求是能够将通常看不到的隐患用一种机制来把它挖出来，显然这件事情算是失败了的，至少我认为是个失败。无论你是否属于管理层，在做 管理、决断的时候所需要具备的素质还是很多的，笔者不可能面面俱到的描述。这里的两个“运动”表明，如果连基础的一些素质都没有具备的话，做管理工作会将 一群人引向成功之母那里。

看起来笔者似乎只有失败的例子，没有什么值得分享的了？不是的，在09年底的又一次自动化运动中，笔者的主管征求组员们的意见，最终以质量承诺换取了低于部门10%的 自动化覆盖率指标。事实证明，这是这两年来最让笔者开心的事情了，因为在随后一年多的每日回归里面，我们组的脚本通过率平均高出平均水平很多，稳居部门第 一，而测试缺陷发现和对回归测试的帮助也是有目共睹的。由此一事，笔者总结出一点经验：测试主管一定要懂得拒绝不切实际的想法、拒绝不客观行为和超出下属 能力范围的工作。

我们没有理由去质疑领导们的初衷，没有哪个领导无知到只会用面子工程来装点自己，但是领导的思想在传达和执行的过程中是否被正确理解和分析是很关键的。如今，笔者看到我们部门在进行新一轮的运动：接口测试自动化和算法测试自动化，在搭建起STAF平台之后，似乎没有看到测试框架的搭建和组件的抽离便开始让所有测试人员投入到代码编写的洪流中去了。不知我获得的信息和理解是否有误，但愿上天有好生之德，保佑我们不再为一堆散乱无组织的代码去买单了罢。