测试人员如何甩锅
https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483935&idx=1&sn=475e71eaf462135b458d13eeff3d9b7c&chksm=c0fb142af78c9d3c657e5839816b0c5855970931992bce5870ecf60c2619bdbf5df59a5ebe1c&cur_album_id=1979310371207184387&scene=189#wechat_redirect
最近看到好几次有人问,测试人员要如何甩锅。这都2022年了,还有这么严重的“筒仓”思维?我们可是一个Team啊,不都是在玩敏捷研发么?说好的免责文化呢?全员质量意识和质量内建一直是团队期待发生的事(如果真的发生了,可能很多测试人员都会没饭吃)。你以为我会说他们做得不对么?其实吧,还真的不能直接怪他们。这事,得分开来说说。
感知团队的质量下线在哪里
测试活动其实是很依赖团队氛围的,因为测试并不是产品的源头,也不是实际的生产者。做为“辅助”,就要有辅助的觉悟。测试人员首先要学会的,就是要感知团队整体质量观的下限在哪里。如果团队成员,或者是领导对质量并不在意,那么作为产品质量保证的最后一环,其实是比较麻烦的(并不是所有团队都靠产品质量活下去的)。
如何感知团队的质量观呢?个人的小窍门是,观察团队对线上问题的处理时长。为什么不是数量呢?因为数量有可能是团队暂时能力的问题(代码质量差、测试人员能力不足、业务复杂度高等等),但解决时长能真实的反馈出团队对交付质量的态度。如果响应速度快,那么必然是对质量有要求的团队(不管是不是自愿的,有的团队是自我要求,有的是客户的压力),在这种团队中,去尝试改善质量,多背些锅(相信这样的团队也不会乱甩锅。后面会分析),个人感觉也是无妨的。如果对线上问题不敏感,能拖就拖的(或者隐瞒),那也就不要奢望太多,做好过程记录,多发邮件提示风险,然后学会甩锅的本领吧。个人更建议你换个环境。
如何感知团队的质量观呢?个人的小窍门是,观察团队对线上问题的处理时长。为什么不是数量呢?因为数量有可能是团队暂时能力的问题(代码质量差、测试人员能力不足、业务复杂度高等等),但解决时长能真实的反馈出团队对交付质量的态度。如果响应速度快,那么必然是对质量有要求的团队(不管是不是自愿的,有的团队是自我要求,有的是客户的压力),在这种团队中,去尝试改善质量,多背些锅(相信这样的团队也不会乱甩锅。后面会分析),个人感觉也是无妨的。如果对线上问题不敏感,能拖就拖的(或者隐瞒),那也就不要奢望太多,做好过程记录,多发邮件提示风险,然后学会甩锅的本领吧。个人更建议你换个环境。
锅的质量分析
如果是上述第一种团队,我们还是可以认真分析下“锅”的质量的。简单地把线上BUG分成三个等级,便于分析。
简单易现的问题:如果是比较简单就复现的问题,那作为测试人员就要反思下为什么了,这个锅跑不了,还是要有对自己的工作负责的态度。如何避免这类问题的出现呢?有几个小办法:1. 注重测试策略的设计(好多人都忘记这件事了,后面会专门谈谈测试策略的问题),对于每个迭代(版本)的测试重点和测试方法做一次梳理。2. 测试用例设计更全面些,多考虑一些业务场景,更多的确认手段,而不仅仅只停留在页面的操作上。3. 测试用例评审,避免自己陷入测试盲区,让产品和研发一起来确认场景覆盖是否充足。4. 认真执行测试用例,这点很简单,但是很重要。因为人都会情绪低潮,在某些情况下,心存侥幸,可能用例直接就Pass了。
特定场景或者数据才会出现的问题:这种情况,遇到一次,就完善一次用例(如果能自动化,就最好了),同时思考为什么只有这种情况才会出现,类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累,形成自己的经验,这类“锅”,可以团队一起背,但要给出改进方案,不能多次在同一个地方跌倒。
深层次的偶发问题:这类问题其实是提升团队技术能力很好的试验场,集中力量解决掉就是了,更能激发技术宅男们的热情。这类问题,一般情况下做好线上监控,能及时预警,比客户更早或者不能落后太多发现,就可以的,让团队有缓冲解决问题的时间就好(准备好相关的话术,安抚客户也是OK的)。你看,这么一分,是不是心理负担就少很多了,有些“锅”也不是什么坏事。不是么。
深层次的偶发问题:这类问题其实是提升团队技术能力很好的试验场,集中力量解决掉就是了,更能激发技术宅男们的热情。这类问题,一般情况下做好线上监控,能及时预警,比客户更早或者不能落后太多发现,就可以的,让团队有缓冲解决问题的时间就好(准备好相关的话术,安抚客户也是OK的)。你看,这么一分,是不是心理负担就少很多了,有些“锅”也不是什么坏事。不是么。
你的质量观在哪里
看法一:把测试这个职业定义为仅仅是保证系统不出重大事故,一点就蹦的情况出现,其它交给开发,出现BUG就是开发能力不足。因为他们对测试的理解就出现了偏差,所以遇到比较复杂的,难以测到的问题,就放弃努力,给自己找借口。比如自己薪资就那么点,因为能力有限啊,发现不了还能怎么办?比如你行你来测试啊?谁家软件还没有个BUG呢。凡此种种,肯定不会觉得自己应该背这个锅的。
看法二:从自己手中出去的产品,要有最低的质量保证,如果出现问题,及时反思,寻找解决办法,什么“Bug 藏得太深”、“测试环境无法复现” 等理由都不是借口,总结经验教训,努力提升自己。真正把测试当做职业来对待,一定会想到办法解决或者规避此类问题的再次发生。在做好自己的同时,给团队带来正面影响,逐渐影响到其他人。
看法三:通过更好的实践方式,提前预防问题的发生。单测、静态分析、自动化测试,还有现在比较流行的混沌测试,都会帮助我们及早的发现问题。在适当的机会引入敏捷理念,通过自己的能力和实践,协助团队内建质量,培养全员质量意识。
看法二:从自己手中出去的产品,要有最低的质量保证,如果出现问题,及时反思,寻找解决办法,什么“Bug 藏得太深”、“测试环境无法复现” 等理由都不是借口,总结经验教训,努力提升自己。真正把测试当做职业来对待,一定会想到办法解决或者规避此类问题的再次发生。在做好自己的同时,给团队带来正面影响,逐渐影响到其他人。
看法三:通过更好的实践方式,提前预防问题的发生。单测、静态分析、自动化测试,还有现在比较流行的混沌测试,都会帮助我们及早的发现问题。在适当的机会引入敏捷理念,通过自己的能力和实践,协助团队内建质量,培养全员质量意识。
当团队和个人产生冲突时
都说“始于颜值,忠于才华”,对于测试人来说,选择一个团队,一般是”始于金钱,忠于三观“。当个人的质量意识和团队产生冲突时,尽量不要尝试用个人的能力去强行改变什么(除非你和领导有特别的默契)。因为那样会让大家都变得痛苦。
要么,看在钱的份上,随大流,跟着团队走(非常不建议,因为一旦养成习惯,当你离开这个团队时,会失去很多机会)。
要么,离开这个团队,去寻找更高层级的圈子。
小结
你把时间花在哪里,就会在那里得到收获。如果你把过多的精力花在学习如何甩锅上,那么你将会有N多个理由去放弃质量。有这时间,还不如去尝试寻找一个可以提升自己能力的团队。尝试通过识别团队的质量观,同时认清自己的质量观,找到一个适合的团队,去卷吧。 你,学会甩锅了么?今天就聊到这啦,接下来,我们聊点什么呢?敬请期待。