昨天看了个电影《摇滚教室》，内容是一个不靠谱的摇滚乐狂热屌丝，偶然机会充当某精英小学的代课老师，他不教孩子科学文化知识，却教孩子们摇滚乐，组建school of rock 乐队参加比赛。

       大家都会觉得不靠谱吧，在学校的任务就是学习，考出好成绩，这就是我们从小接受的教育。延续到工作中也是如此，作为一个测试工程师，就要能够努力找出最多的Bug，做出强大的自动化测试平台，构建完美的测试流程和质量保证体系…

       下面我们来看下什么才是不靠谱的行为

       Bug数量衡量绩效

      Bug数量衡量绩效的方法五花八门，曾经所在公司的研发团队，在办公室的墙上订了一个板子，展示每个测试工程师每周提交的Bug数量和组内排名，还有开发工程师的修改Bug数量和组内排名；还有我的一个前同事所在团队，部门经理要求每个测试工程师在周报中列出本周提交的Bug数量，提交Bug少或者甚至没有提交的会被谈话。

      我相信以Bug数量来衡量绩效的危害现在已经有越来越多的人体会到了，一味追求缺陷数量，必然会陷入发现的缺陷越来越多，产品质量并不能提高多少，反而进度无限延期的窘况。就不在这里做详细解析了。

       要说这种行为也不是完全不靠谱，在抗日时期，用小米加步枪打飞机也是很有效的办法。那么在测试团队组建初期的摸索阶段，或者为了应付短期着急上线的项目或产品，靠这种土方法来激励士气是没有错的。如果把这种应急的手段作为长期的目标，那么就完全不靠谱了。

       我见识过一些项目经理或测试经理，当初他们作为员工期间，曾经被组内公认是提交Bug最多的，或者是修改Bug最快最多的，因为工作绩效的突出升级做了管理。那么就是说有一些现在的测试经理甚至总监，很多是从当年Bug数量大战中拼出来的，没准在2007或2008年因为提交Bug最多获得过公司内最优测试工程师。可是请反思一下那时的生存法则还能适用于现在的环境吗？

       构建强大的自动化测试平台

       我想很多人都常常听到管理层的或者项目组里测试老人们，对于自动化测试提出各种各样的需求。比如“自动化用例覆盖率达到100%，能够适用于Web系统、PC端程序、数据库、接口甚至移动应用的测试，能够自动生成测试用例，测试人员能够快速上手，提供界面化管理和操作平台，测试人员不需要懂代码就可以实现自动测试…”

       如果你做的轻量级自动化测试框架无法实现这些需求，又需要测试人员具备代码能力才能使用，可能会引来管理层的质疑“那要你们有什么用？价值体现在哪里？不要给我说什么构建质量安全网这种防御性质的价值体现…”

       我想追求高大上的自动化平台，没有错，如果有公司财力物力和人力的支持，这种造福人类的事情还是可以做的。

       可是为什么会形成这种现状呢？我想是一些别有用心或者好大喜功的人，向喜欢数据说话的管理层吹嘘太多了。如果一个公司开发流程还处于小作坊阶段，开发人员还是靠堆砌代码来开发项目，测试人员还是靠堆砌bug来实现价值。领导就要小心那些像你吹嘘什么高大上的自动化测试平台的人了。

        构建完美的测试流程和质量保证体系

       当初为了找工作为了应付笔试，看了很多关于测试流程的相关资料，来应付这些笔试题“V模型包含哪些阶段？测试包含哪些阶段？测试应该从什么阶段介入项目？列举测试评审的重要性？…“。 工作多年才发现，实现CMMI5的软件服务企业，项目还是小作坊流程的比比皆是。其实更痛苦的事是，突然公司要所有项目走CMMI的体系，PMO来监控和考核项目的流程是否规范。

       然后是写了一大堆文档用例，写了一大堆文档，进行了无数的评审；最后是文档用例太多太细，维护工作量大而放弃维护成了摆设；什么测试计划、测试规范、测试策略、问题记录列表，一个项目下来形成了太多碎片化的文档，没有时间去归纳整合，为了应付而浪费了真正思考和实践的时间；参加评审仍然是一言堂，管理层决策，发表尖锐的评论和建议常常被和谐，所以只好针对具体细节展开无休止的讨论，最终以和稀泥的方式完成评审。

       形成这种情况的原因我想和一部分人的狭隘思想有关：作为测试管理者，总要做一些能够实实在在体现测试部门价值的东西，可是光靠测试团队在短期内真正地提高项目或产品质量是不可能的，那么通过建立形式上的规范和体系便可以快速确立自身的地位。

      反思

      回到电影《摇滚教室》，他虽不经意，却带给孩子们真实的音乐体验旅程，孩子们收获的成长并不是考试分数的提高，却是心智发展历程中的一次飞跃。某些被大家认同的靠谱行为，我们是否应该真正反思下是否值得去做。

      两年前关于是否需要专职的QA的热烈讨论，我作为一个测试工程师，一开始思想上是坚决站在维护测试正义的一方。我当时觉得你技术大牛也不能因为测试工程师不会测试某个随机算法程序，就否定我们测试工程师和测试工作的价值。

      这两年经过互联网的发展，移动互联网的兴起，传统的研发测试方式都在受着挑战。也许正如有些人所说专职测试工程师这角色真的就会不存在了，或者更靠谱的说应该是原来的测试角色会被重新定义，执行测试工作的可能是开发工程师或者是计算机，也可能是用户。

       那么对于目前的测试工程师，我们不应把自己局限于“Tester“这个角色本身，更不要为了指标和形式去做一些好看却不实用的事情，而应该去真正关注项目或产品这个交付物本身。不要总想着我测试工程师应该站在用户角度攻击项目或产品，甚至是攻击开发团队存在的问题，而是应该站在整个团队的角度，把产品或项目作为自己的孩子一样，从技术细节和实现细节上去分析考量，做一些真正对项目对团队有帮助的工作。

｛测试窝原创文章，作者：熊志男｝