为什么互联网公司需要测试人员

目录

引言

身边项目的例子

 对测试大致会有以下几个方面的误解

重要的测试方法论

为什么互联网公司需要测试人员   

测试人员地位为什么在团队中没有足够的被重视？

bug悬赏

对测试人员考核的一些思考

总结

---

引言

            偶然在知乎上看到一篇帖子：为什么互联网公司不开除测试，转而让大众来测，找到一个bug给100元？，几年测试经验下来，看到大家的讨论，深感心有戚戚焉，于是也想浅谈测试人员对于公司的重要性。

身边项目的例子

            大致剧情是： 开发团队因为某某原因，感觉测试人员“有些多余”，测试工作可以自己做。于是不再让测试团队跟，于是这么进行了两三次后，实在受不了了线上“控制不住的”问题，于是又把测试人员请了回来。、

 对测试大致会有以下几个方面的误解

• 将开发阶段、测试阶段完全剥离
• 误认为测试只是在产品做出来之后，使用它，找bug
• 忽略了发现bug的时间点越靠后，修复它所要付出的代价就越大
• 认为测试人员就是找bug的
• 认为测试就是在界面点点点，找几个茬

重要的测试方法论

         找bug或bug预防应该始终伴随着产品的各个阶段，这里有个比较形象的比喻：敲钉子，如果一口气敲完了才发现，敲歪了，那就得拔出来重新来，可是东西上已经有一个很深的洞了。所以，对质量把控的两个方法论：

• 质量预防。事先定好钉子的位置，方向，需要的深度等等；
• 实时检查。敲一敲，检查一下，随时纠正方向，确保前进的大方向是正确的。

            测试的目标：

测试的核心职能：测试产品与需求(产品需求->用户需求)的契合度

 

为什么互联网公司需要测试人员   

         对于测试工作为什么不直接交给开发/产品/其他人员去做，反而雇佣专门的测试人员，可以使用下面的思路来回答这个问题：

• 测试是一项工程，需要计划、策略、方案。非专门人员，无论从技巧、心态、方案上都无法很好胜任长期的质量保证
• 测试需要对产品的透彻理解，需要对用户的同理心，需要对市场的把握，需要足够好的大局观，需要足够的耐心，需要一定的技术功底，需要宽泛的知识面，需要良好的沟通能力，需要能够协调团队中不同角色。60分的测试人员市场上大把大把的一大堆，但接近100分的测试人员实在非常紧缺，二者对于产品的影响就是：60分人员产出60分经常差强人意的产品；而100分人员产出的是稳定&可靠&体验超爽的“网红”产品。
• 质量保证需要从有别于产品、开发、设计的视角来看待整个产品周期
• 需要专门人员通过各种技术手段和流程改进，逐步的解放团队内部人员，让他们把精力放在对产品的把握上。
• 质量保证既需要方法论，有需要效率，别的人员不能同时具备
• 产品需要不同层面的质量(可用、易用、好用、爱不收手)
• 非测试人员或许能碰得到BUG，但不代表测得出BUG。正如：觉得电影不好看，不一定就能拍出好电影。

总结：收益>投入时，投入才值得，这或许是对为什么需要测试人员的最好回答了。如果将测试人员看做是项目投入的话，那么其所能产生的收益必定是更大的，换言之，使用专门的测试人员是值得的投资。

测试人员地位为什么在团队中没有足够的被重视？

            1. 无论是否熟悉互联网公司团队合作模式，相比产品人员、开发人员，测试人员工作往往由于处于项目的中后期，因而往往产生了这样一个印象：

没有产品人员/开发人员，根本出不了产品；而没有测试人员，大概也是可以的。

          2. 对于产品层面的直观印象是：

            你的团队有测试人员，用户/其他人员不会觉得你的产品好牛逼；

            但你的团队没有测试人员，用户/其他人员会觉得你的产品好low

           3. 测试人员缺少强有力的数据支撑自己的重要性：

            现在几乎所有大中小型公司，考核测试人员的指标越来越偏向于开发能力了。如果测试人员能开发出一个测试工具/平台，彰显自己的开发能力，不仅可以通过分享、工具推广来增加自己的影响力，更可以在晋升答辩中获得优势；

            而对于产品层面的直接影响，缺少类似开发能力这么明显的衡量标准。除非负责的产品直接有关收入、用户量等指标，而测试人员又恰恰新提了一个方案，增加了收入、用户量等（当然这种机会实在是千年难遇啊，毕竟90%的产品可能非人为可以控制）；而实际项目往往面临的是下面的场景：

测试人员对产品层面进行了种种优化建议/改进，但除了多一些bug外，似乎也没有多少说服力来证明测试人员对产品层面的影响           

bug悬赏

众测平台：给符合资质的测试人员分派测试任务，最后根据 Bug 的数量或者测试任务的奖励方式给予报酬

感悟:      这或许是鼓励测试人员以外的人员，来参与测试的最好方式了吧

对测试人员考核的一些思考

• 为什么几乎没有公司根据bug的数量/严重级别，对测试人员进行“悬赏”(因为大多数公司而言，测试任务量大/发现大量bug的项目在许多资源方面 并没有比 成熟业务 有利，大多数情况下，反而更被动)
• 当测试人员疲于项目测试，整天忙的晕头转向时，到绩效考核/晋升时却发现无“重量级话题”可说；而一些项目测试比较“悠闲”

的人员，反而可以有时间去持续集成、自动化开发等等，去做一些在考核时十分抢眼的事情。两类人员常常限于自己的循环之中

• 项目测试中，由于业界普遍对自动化的推崇，实际项目中往往出现了以下现象：

1）为了自动化而自动化。现在一说到测试执行，如果说还没有自动化，直觉上好像在进行“很low”层次的测试一样

2）强调自动化的代码覆盖率，而非从整体测试策略来思考具体的测试执行方案

3）大量自动化覆盖率、高运行通过率的情况下，仍然频出线上问题。这里不禁有一个疑问：如果自动化真的减少了人力投入的话，那么节省下来的人力究竟对确保安全、无故障上线起到了什么作用呢？

总结

     目前测试界的现状是：对测试人员角色理解相对不太深入、测试人员的价值没有被足够重视、对测试人员考核的普遍倾向。在当前现状下，如何在整个团队中发挥测试角色的作用，又能对自己(如果你是QA的话)带来成长/考核方面的益处呢？以下文章将对这个话题做更多探讨。