V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
julyedu
V2EX  ›  推广

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

  •  
  •   julyedu · 2019-01-12 18:56:35 +08:00 · 1804 次点击
    这是一个创建于 2142 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    知乎原帖:

    https://www.zhihu.com/question/27236089

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

    对测试的常见误解

    关于测试,大致会有以下几个方面的误解:

    将开发阶段、测试阶段完全剥离;

    误认为测试只是在产品做出来之后,使用它找 bug ;

    忽略了发现 bug 的时间点越靠后,修复它所要付出的代价就越大;

    认为测试人员就是找 bug 的;

    认为测试就是在界面点点点,找几个茬。

    重要的测试方法论

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

    质量预防。事先定好钉子的位置、方向、需要的深度等;

    实时检查。敲一敲,检查一下,随时纠正方向,确保前进的大方向是正确的。

    测试的目标:

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

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

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

    测试是一项工程,需要计划、策略、方案。非专门人员,无论从技巧、心态、方案上都无法很好胜任长期的质量保证

    测试需要对产品的透彻理解,需要对用户的同理心,需要对市场的把握,需要足够好的大局观,需要足够的耐心,需要一定的技术功底,需要宽泛的知识面,需要良好的沟通能力,需要能够协调团队中不同角色。60 分的测试人员市场上大把大把的一大堆,但接近 100 分的测试人员实在非常紧缺,二者对于产品的影响就是:60 分人员产出 60 分经常差强人意的产品;而 100 分人员产出的是稳定&可靠&体验超爽的“网红”产品。

    质量保证需要从有别于产品、开发、设计的视角来看待整个产品周期。

    需要专门人员通过各种技术手段和流程改进,逐步解放团队内部人员,让他们把精力放在对产品的把握上。

    质量保证既需要方法论,又需要效率,其他人员不能同时具备。

    产品需要不同层面的质量(可用、易用、好用、爱不收手)。

    非测试人员或许能碰得到 Bug 但不代表测得出 Bug。正如觉得电影不好看,也不一定就能拍出好电影。

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

    测试人员地位为什么在团队中未被足够重视?

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

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

    1. 对于产品层面的直观印象是:

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

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

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

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

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

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

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

    Bug 悬赏

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

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

    为什么几乎没有公司根据 bug 的数量 /严重级别,对测试人员进行“悬赏”?因为于大多数公司而言,测试任务量大 /发现大量 bug 的项目在许多资源方面并没有比成熟业务有利,大多数情况下,反而更被动。

    当测试人员疲于项目测试,整天忙得晕头转向时,到绩效考核 /晋升时却发现无“重量级话题”可说;而一些项目测试比较“悠闲”的人员,反而可以有时间去持续集成、自动化开发等,去做一些在考核时十分抢眼的事情。两类人员常常限于自己的循环之中。

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

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

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

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

    写在最后

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

    特别提醒:免费学习海量 AI 课程,请访问七月在线官网:www.julyedu.com

    geekvcn
        1
    geekvcn  
       2019-01-12 21:31:17 +08:00 via iPhone
    机智广
    Flobit
        2
    Flobit  
       2019-01-12 23:02:17 +08:00 via Android   ❤️ 1
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2733 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 07:00 · PVG 15:00 · LAX 23:00 · JFK 02:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.