测试管理 测试如何提高自己的话语权

CKL的思考 · 2022年01月12日 · 最后由 离是伞中仙 回复于 2024年07月10日 · 5321 次阅读

今天我们聊聊一个比较有趣的话题。某天有人在群里问了一个问题:一名普通的测试人员如何提升在团队中的话语权。笔者在测试很没有话语权的团队中待过,也在测试具有上线一票否决权的团队中呆过,对于 “话语权” 这个事,还真没太注意过。在测试拥有上线一票否决权的团队中,基本上也没见测试动用过那个权利(曾经动用过,而且还真的不让上线了,所以这个权利是真的可以被使用),因为它对团队的伤害太大,使用它,往往意味着整个团队对项目质量已经失控了。个人更喜欢用 “影响力” 来表达测试在团队中的地位,可能发问的那位同学也是这么想的吧。那么如何提高测试自身的影响力呢?

01 增强自己的业务能力

在笔者面试测试人员的时候,都会问到一个问题:请描述下你测试的一个项目,它的基本业务流程是什么样的,业务数据的流转是怎么样的,哪些场景会对此业务产生影响。很多时候,面试候选人都无法很好地回答这些问题。作为测试人员,我们不应该仅停留在对页面数据的增删改查验证。而是需要协助研发人员一起把业务规则梳理清楚,并提醒可能的潜在风险,这些事都需要测试员对业务有深入的了解。能够从产品的一句话需求中,“挖” 出一些有价值的信息(参考从测试看需求)。

举个例子,我们现在常用的健康码,从业务的角度出发,作为测试人员的你,可以提出哪些问题,来帮助研发同学梳理业务呢?如果你的答案是直接找产品啊,那也不能说你错,但这样,其实你就失去了一次影响研发的机会。而且,如果你不是带着问题去找产品,你所获取的信息也会相当有限。
我会准备好以下几个问题:

用户信息如何识别?怎么确认当前登录的用户谁,如何认证?
为了生成这个码,我们需要和哪些公共资源接口对接?还是都是我们自己做?
绿、黄、红码的变化规则是什么?
某个地区突然被升级成高风险,系统如何获得这个信息?
当获取到第 4 点的信息时,我们的系统将如何响应?
如何保障这个码不会被篡改?
。。。。。。

带着这些问题,和研发一起找产品聊,你觉得研发会不喜欢这样的测试么?会没有影响力么?

02 能够和研发同频交流

你是否足够了解被测系统的业务构架是怎么样的?基于当下的微服务拆分,你是否能准确地了解哪些服务是做什么用的?它们之间是如何通信的?当研发的同学在交流时,提到服务注册、API 网关、Mycat、Redis 集群、Kafka、Elastic Search 等词汇时,你能否 GET 到他们在聊什么?知道这些技术的基本应用场景和优缺点么?如果你只能 “嗯,哦、啊” 而插不上话时,你如何体现自己的影响力?你又不是捧哏的。并不是要求你和开发的技术能力要一样,而是至少你要了解这些组件的基本原理,能听得懂,在适当的时候能和他们进行正常的沟通,如果能提一些意见,那就更好了。这几天因为西安一码通的事,分布式和高可用又被炒了一波,看看那些词,你能理解的有多少呢?

03 具备自己的测试思维

对于有一定工作年限的测试人员,一定要形成自己的测试思维,当领到一个测试任务时,知道该如何去验证,能够分清测试重点。而不是人云亦云,被开发牵着鼻子走。这个其实也是基于前面 2 点,形成自己的测试思维,举几个例子。

  1. 如何验证需求真的被实现了?
    以前遇到一个需求,很简单,为了保护个人隐私,在页面上,需要把电话 18788888888 显示成 187**888。是不是很简单,那么如何验证研发真的实现了呢?如果你只是看页面的显示,那是不够的。至少你要找到这个接口,看看接口层返回的是 18788888888 还是 187888,如果接口返回的是 18788888888,那在页面上显示成 187***888 又有什么意义?(不要笑,这是个真实的案例,不要高估研发团队的能力,需要自己有验证的能力)

  2. 如何提供有效的 BUG 信息 ?
    当我们提交一个 BUG 时,除了常规的那些必填项外,是否还能够提供一些更有价值的信息,来协助开发定位问题?仅仅一个截图是不够的。至少你还需要提供一些日志信息以及你的测试数据。这样有两个好处:第一,可以帮助我们确认是否真的是 BUG。当你可以在众多的微服务中找到这个 BUG 的异常信息时,至少可以说明你对这个系统有足够的了解。第二,当你觉得这个是 BUG,而又找不到什么关键信息时,你需要再次确认下这是否真的是一个 BUG?减少不必要的无效 BUG ,同时又能提升研发定位问题的测试人员,研发肯定是喜欢的,不是么?

  3. 要有自己的逻辑思维
    遇到问题要有自己的思考过程。不要被带偏,特别是在做一些专项测试时,更要注意完整的逻辑闭环。当研发提出某些问题不是问题,或者只能那么实现时,需要自己去思考是否合理,而不是就同意了。同时,对于自己给出的数据链或者结论,要形成完整的闭环。有一次看到同事的一份性能测试报告,其中有一条结论大致是这样的:对比发布 200 个 API 和 1000 个 API 的压测结果,无认证 API 最大 TPS 分别为 10797.5 和 4623.4,相差 2.3 倍;通过对比可知,发布的 API 数量影响系统的处理能力。
    我不知道大家对这个结论怎么看,仅仅通过两个数据,就轻意下结论,这种做法并不可取。

04 以上要求真的高吗

一名测试人员具备 “懂业务、懂技术、有思维” 的能力,真的很难么?如果你工作 3 年以上,真的不难,如果不具备,那需要反思的是自己,而不是去争取所谓的 “话语权”。当你做好自己的本职工作,同时又能给团队些许帮助时,你就具备了一定的话语权。单纯行政上的话语权,当你能力不够时,只会沦为被嘲笑的对象。
现在团队对测试的要求已经更高了。可以参考林冰玉老师最新的文章:构建测试的体系化思维(基础篇)。个人非常推荐大家好好看下这篇文章,如果你真的达到了,那么,你一定会有话语权的。

原文连接:https://mp.weixin.qq.com/s/1jOjZSqKoHH7LwukV7zyTQ

共收到 4 条回复 时间 点赞

完全赞同。话语权建立在自身实力基础上。

当然有些垃圾团队只需要工具人和背锅侠,这种团队趁早离开就行。

说得对

非常赞同,具备团队其他成员不具备的能力,能够给团队带来增益。

CKL的思考 测试的最终产物是什么 中提及了此贴 07月09日 16:51
CKL的思考 测试的最终产物是什么 中提及了此贴 07月09日 16:51

隐藏电话号码那个我真遇到过类似的,一个排班功能要求对不同组角色不可见,页面做了处理,但是接口返回了应该被隐藏的内容。后面是线上发现这个问题后做了接口返回优化,但是我当时确实没想到去看接口返回。所以我就总结了一个经验,下次在测这种角色不同页面展示不同的时候应该关注页面展示 + 接口返回

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册