反思: 我们成了测试的路径或许错了

本帖已被设为精华帖！,

最近一直在想一个问题，为什么测试总是疲于奔命，在互联网企业高速迭代的情况下，测试可以说是最苦的一群人了：

• 从结果看：在每一个成功互联网故事的背后，从来没有一个提到过测试的故事，都是产品，架构师，开发。。。。。。
• 从项目交付看：所有的延期最后都会变成压缩测试时间和加班的二选一
• 从心态看：开发的心态是就算我出了bug，问题不是我一个人的，测试会和我分担；测试的心态是，我要好好测，线上千万不要出大bug；两者压力系数其实是不一样的
• 从人员配比上看： 很多公司都说测试开发比例，一般最少都要1:3，意味着测试不能专注一件事情,同时很显然，也无法像开发一样去精通某项技术，某个模块
• 从信息对称情况看： 开发和产品商量了一个新东西，然后拍拍测试肩膀说，我们明天想上线，你测试一下吧；测试说你们搞什么东西我还不知道呢，产品说不行，老板说一定要明天上；很多信息其实传不到测试这里，测试更多是别人的资源
• 从技术看： 测试经常被抱怨技术不行，其实技术现在太庞杂了，从前端，移动，到后端，中间件，数据库，可怕的是测试可能会和这些人同时打交道，而每个技术都不同，被任何一组人觉得技术不行，都可能被抱怨；然后如果每个你都比较清楚，你还是个人嘛？
• 从期望看： 老板对测试的期望要么就是很高，希望线上不出现重大的问题，然后测试其实完全没有这个能力去保证大型互联网公司线上不出问题，高可用这种太复杂了，超过测试能力范围太多太多；或者期望不出弱智问题就可以了，但是这个期望你觉得测试在老板眼里，前途在哪里？

说到底，在目前互联网公司如此快速迭代开发，又有很多流程不规范情况，大部分的测试就是没有能力去做好通常意义上面测试应该做的事情，比如线上bug少，比如按时交付，比如少加班，比如可以一定程度上保证质量；要想做好一个测试，或者达到老板期望的一个测试，其实这个测试的综合能力包括了代码能力，项目管理能力，对于业务的理解能力，对于流程管理，风险分析的能力是需要高于开发的，才可能在1:3或者资源更少的情况下做好测试的活。见过太多开发埋头开发，不管需求是否合理，不管是否有人需要知道功能的上下文，总之就先码上代码再说，好了就给测试测，至于需不需要给被人解释一下，同步一下情况，基本上是不问不说，问了嫌烦的状态；这也就要求测试有比较好分析能力，可以提问，可以一步步自己分解问题，同时还需要比较好的沟通技巧和技术背景，和开发沟通，开发经常出一些莫名其妙的名词和黑话来，如何去理解它，如何去深入的沟通其实不是一个非常初级的工程师有能力做到的。

所以我认为大部分的我们成为测试的路径错了，至少我们应该做了几年开发，了解了不少项目之后再来做测试或许比一开始没有代码基础做测试会好一点，有技术，有沟通经验；这样才有可能做好或者承担起质量的重担，否则我不认为大部分的测试有能力担当保证质量(QA)的角色，最多就是产品质量的一个替罪羊而已；如果只是当替罪羊，那么这个职位的职业发展又在哪里呢？

我的观点是测试在承担的压力，责任上面其实有可能超过了一般的开发，但是我们的技能可能不如开发，这点我觉得是不合理的；测试需要更有技术能力的人，更有经验的人担当，而不是让因为编码能力不足而来做测试的人去当测试。