• 不通过Bug数量等量化数据如何界定测试人员的价值或者贡献?
  • 发布于 1个月前
  • 95 热度
    0 评论
近日有同学私信说:不通过BUG数量等量化数据,那么如何界定测试人员的价值或者贡献?本文聊聊自己对于测试价值的思考。

01
需求端的价值:从质量构建和缺陷预防的角度看,测试人员需要尽早地介入,了解需求。在需求端,测试的价值至少应该包含三类
验收标准:测试人员需要明确某个需求的验收标准是什么,实例化出场景来确认,保证产、研、测三方达成共识,避免需求返工,造成浪费。可参考:从测试看需求
业务逻辑梳理:作为对被测系统最了解的人(使用频率最高的人),需要协助产品经理梳理业务细节,当产品对已有功能做出改变时,需要评估改动点对原有业务逻辑的影响,避免遗漏。
用户体验:系统好不好用,视觉效果是否合理,操作路径是否顺滑等等用户体验的问题,可以在需求端给予确认。

02
测试即服务:把测试活动当成一种服务,在不同的场景下提供对应的服务。如上文的AC,算是对产品的服务。那么对于研发侧,能够提供哪些服务呢?
测试用例服务:在不同的研发环节,提供经过科学设计的高效用例,以便开发能够快速验证自己的代码,保障交付质量。如冒烟用例、流水线用例、showcase用例等。
专项测试服务:当产品达到特定形态后,需要开展如性能测试、安全测试、某类专项测试(安装测试、疲劳测试等)时,测试组能够提供对应的能力进行测试,并出具专业的报告,以便团队做出正确的评估。
缺陷跟踪服务:从缺陷的发现到最终的验证关闭,提供全周期的管理,迭代缺陷及时跟进,遗留缺陷持续跟进。不让缺陷无限期流浪。

03
团队积累:把个人的经验沉淀成团队资产,对外赋能,提升影响力。
过程改进:由于测试参与到了研发的全生命周期,可以观察到所有的测试活动,所以可以更好地地识别出瓶颈点,给出过程改进建议。
风险评估:结合业务需求及研发进度,提前暴露风险,进行风险预警,结合客观条件提出质量预期,帮助团队建立质量信心。
业务沉淀:测试人员积累了大量业务知识,不管是宏观层面还是业务细节,测试人员对自己测过的产品都了如指掌,往往也更容易成为领域专家。在这个过程中的积累和沉淀,对组织来说都是一种有形的或无形的资产。

04
个人价值体现:为了完好的完成以上团队层面的价值,测试人员个人要也需要具备一些突出的能力,形成一定的leadership,进而影响团队,体现自己的价值。

缺陷定位能力:同样一个缺陷,有的测试人员只能在页面上截个图,有的测试人员可以追踪日志、分析代码,甚至给出解决方案(这点笔者并不提倡)。你觉得哪个测试更有价值?

风险识别能力:在需求确认时,能识别出业务风险,在测试过程中能识别出进度风险,在上线前能识别出上线风险,可以极大地极大地保障迭代的顺利进行。
测试策略制定能力:在迭代前,明确测什么(指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求)怎么测(采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等)。可参考你还记得测试策略么
技术攻坚能力:当团队需要开展某类专项测试时,能够承担起对应的责任,从技术和方法上攻坚克难,顺利完成对应的任务。
汇报能力:既要做得好,也要说得漂亮。在适当的场合刷刷存在感,定期做做汇报。让更多的人看到你的能力,认可你。潜移默化地,你的价值就最大化了。

05
当我们做好缺陷预防后,就可以提升研发的交付质量。有的人会担心BUG少了,老板会认为测试就可以减少人力,是不是会把自己做没了?其实大可不必有这样的担心。当研发交付质量提升后,测试可以把时间腾出来做更多有意义的事,比如探索性测试、可观测性测试等,这些测试活动,不论对个人,还是对团队,都是有利的。

只有在不规范的团队,才会存在天天救火的情况。救火多了,看似你很重要,但是能力没有得到质的提升,未来的上升空间也就没了。做好测试该做的事,讲好测试该有的故事,才能真实地体现测试人员的价值。
用户评论