测试基础测试人员如何甩锅

CKL的思考 · 2022年01月26日 · 最后由 xyhiacb 回复于 2022年06月24日 · 4459 次阅读

最近看到好几次有人问，测试人员要如何甩锅。这都 2022 年了，还有这么严重的 “筒仓” 思维？我们可是一个 Team 啊，不都是在玩敏捷研发么？说好的免责文化呢？全员质量意识和质量内建一直是团队期待发生的事（如果真的发生了，可能很多测试人员都会没饭吃）。你以为我会说他们做得不对么？其实吧，还真的不能直接怪他们。这事，得分开来说说。

01 感知团队的质量下线在哪里

测试活动其实是很依赖团队氛围的，因为测试并不是产品的源头，也不是实际的生产者。做为 “辅助”，就要有辅助的觉悟。测试人员首先要学会的，就是要感知团队整体质量观的下限在哪里。如果团队成员，或者是领导对质量并不在意，那么作为产品质量保证的最后一环，其实是比较麻烦的（并不是所有团队都靠产品质量活下去的）。

如何感知团队的质量观呢？个人的小窍门是，观察团队对线上问题的处理时长。为什么不是数量呢？因为数量有可能是团队暂时能力的问题（代码质量差、测试人员能力不足、业务复杂度高等等），但解决时长能真实的反馈出团队对交付质量的态度。如果响应速度快，那么必然是对质量有要求的团队（不管是不是自愿的，有的团队是自我要求，有的是客户的压力），在这种团队中，去尝试改善质量，多背些锅（相信这样的团队也不会乱甩锅。后面会分析），个人感觉也是无妨的。如果对线上问题不敏感，能拖就拖的（或者隐瞒），那也就不要奢望太多，做好过程记录，多发邮件提示风险，然后学会甩锅的本领吧。个人更建议你换个环境。

02 锅的质量分析

如果是上述第一种团队，我们还是可以认真分析下 “锅” 的质量的。简单地把线上 BUG 分成三个等级，便于分析。
简单易现的问题：如果是比较简单就复现的问题，那作为测试人员就要反思下为什么了，这个锅跑不了，还是要有对自己的工作负责的态度。如何避免这类问题的出现呢？有几个小办法：

注重测试策略的设计（好多人都忘记这件事了，后面会专门谈谈测试策略的问题），对于每个迭代（版本）的测试重点和测试方法做一次梳理。
测试用例设计更全面些，多考虑一些业务场景，更多的确认手段，而不仅仅只停留在页面的操作上。
测试用例评审，避免自己陷入测试盲区，让产品和研发一起来确认场景覆盖是否充足。
认真执行测试用例，这点很简单，但是很重要。因为人都会情绪低潮，在某些情况下，心存侥幸，可能用例直接就 Pass 了。

特定场景或者数据才会出现的问题：这种情况，遇到一次，就完善一次用例（如果能自动化，就最好了），同时思考为什么只有这种情况才会出现，类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累，形成自己的经验，这类 “锅”，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。

深层次的偶发问题：这类问题其实是提升团队技术能力很好的试验场，集中力量解决掉就是了，更能激发技术宅男们的热情。这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，就可以的，让团队有缓冲解决问题的时间就好（准备好相关的话术，安抚客户也是 OK 的）。
你看，这么一分，是不是心理负担就少很多了，有些 “锅” 也不是什么坏事。不是么。

03 你的质量观在哪里‍

最后，再聊聊测试人自己的质量观。每个人走上测试这条路的理由五花八门，也导致了大家对质量这件事本身的看法也有很大的不同。

看法一：把测试这个职业定义为仅仅是保证系统不出重大事故，一点就蹦的情况出现，其它交给开发，出现 BUG 就是开发能力不足。因为他们对测试的理解就出现了偏差，所以遇到比较复杂的，难以测到的问题，就放弃努力，给自己找借口。比如自己薪资就那么点，因为能力有限啊，发现不了还能怎么办？比如你行你来测试啊？谁家软件还没有个 BUG 呢。凡此种种，肯定不会觉得自己应该背这个锅的。

看法二：从自己手中出去的产品，要有最低的质量保证，如果出现问题，及时反思，寻找解决办法，什么 “Bug 藏得太深”、“测试环境无法复现” 等理由都不是借口，总结经验教训，努力提升自己。真正把测试当做职业来对待，一定会想到办法解决或者规避此类问题的再次发生。在做好自己的同时，给团队带来正面影响，逐渐影响到其他人。

看法三：通过更好的实践方式，提前预防问题的发生。单测、静态分析、自动化测试，还有现在比较流行的混沌测试，都会帮助我们及早的发现问题。在适当的机会引入敏捷理念，通过自己的能力和实践，协助团队内建质量，培养全员质量意识。