测试员就是“背锅侠”？学会这些，扔掉测试人常背的3口“锅”
最近发生了一起生产事故，究其根源，事故本身属于架构或者需求层面需要规避的问题，测试人员的责任其实是非常小的，但实际情况是：相关测试人员因此承担了很大的压力，成为质量问题的“背锅侠”。
实际上，测试人员一直处于“背锅侠”的处境，今天就来聊聊，测试人员究竟背了哪些锅？
测试背的第一层锅
产品不能如期交付的锅
我们知道，产品交付排期一般是固定的，很多时候，我们在这个基础上，进行开发测试排期的倒排，而测试作为产品交付的最后一个环节，经常被严重压缩排期，场景比如：
研发未能按时提交测试版本；
研发如期交付，但功能并未开发完，或者交付质量很差。
上述两种场景非常常见，尤其是第二种场景，这时候测试人员几乎是有口难言，人家按时提交了，交付质量差也怨不得人家，但因此带来很多测试成本，原来评估的排期根本不够用。
更有甚者，虽然交付测试，但部分功能未开发完，然美其名曰“敏捷测试”，这里不是说敏捷测试不好，只不过实际过程中，敏捷测试被滥用了，因此带来很多测试人力的浪费和排期挤压。
这两种场景，带来的直接后果，就是测试排期被严重压缩，如果产品未能如期交付，第一个被拿出来的理由一定是：未完成测试。
而为了不背这个锅，测试人员只能压榨自己，逼自己如期完成。这是测试背的第一层锅：产品不能如期交付的锅，而为了如期交付，测试人员只能压榨自己，加班加点。
测试背的第二层锅
质量不符合预期的锅
在产品使用过程中，如果出现问题，第一个被问责的对象就是测试：测试人员为什么没有发现该问题？
而因为几乎大部分问题都能定性为测试案例未覆盖，所以测试经常需要背“质量不符合预期的锅”。
之所以背这顶锅，根本原因是业内人员对测试人员的职责定位有误。
大部分人认为测试的职责就是为质量负责，且是负全部责任，只要是质量问题，测试就需要承担起来。
但，请问质量是测试出来的吗？显然不是，质量是设计出来的。
一个坏透了的架构设计，注定产品质量会漏洞百出，测试无法穷尽所有场景发现所有问题。一个好的架构设计，在设计层面就规避掉了几乎所有潜在风险。
当一个产品漏洞百出时，一定是架构设计的不够合理，这时候无论怎么测试，质量都不会太好，因此，当问题出现时，不应该去问责测试为什么没有发现，而是去反思架构设计。
总结来说，很多时候，测试成了架构设计不合理的背锅侠。
当然，这个结论的前提是，这个问题的确是架构的问题。如果出问题的是核心流程，测试的确需要承担一定责任，毕竟基本功能需要确保无问题。
测试的职责是验收产品主要功能满足要求。
测试背的第三层锅
紧急出版本的锅
很多时候需要紧急出版本修复问题，这时候，测试排期几乎被严重压缩。然后，测试还要担着交付后质量无问题的责任，这两者其实是互相矛盾的存在：为了保障质量，需要充分的时间去测试，而排期被严重压缩，几乎没时间充分测试，测试人员深陷其中，苦苦挣扎。
总结来看：
一方面产品交付前，测试排期被严重挤压，测试需要加班加点去完成测试，而由于排期被压缩，测试可能无法充分展开，存在质量隐患。
另一方面，产品交付后，如果真的出现质量问题，测试又会成为第一个被问责的对象，而为了紧急修复问题，测试又需要加班加点去完成测试，而这时候测试周期往往被严重压缩，无法充分测试，进而又埋下了质量隐患。
这不是“背锅侠”是什么？
如果团队研发能力很弱，且对交付质量要求很高或者事故容忍能力很低的时候，测试面对的压力会被急速扩大，成为“超级背锅侠”。
为什么呢？因为研发能力弱，代表潜在质量问题会很多，测试复测成本非常大，且交付的产品从根上就注定了功能不稳定，导致事故频发。如果这时候产品对事故的容忍能力很低，那么后果就是测试需要频繁的被问责，以及被要求完成紧急版本的测试。这种情况下，压力被严重放大。
如果产品对质量问题的容忍度较高，那么测试人员暂且还可以承受住这个“冤屈”，而如果团队研发能力很弱，且对交付质量要求很高或者事故容忍能力很低的时候，就需要考虑“伸冤”了。
如何伸冤
列举几条：
摆正测试人员的职责范围，质量是设计出来的，不好的设计一定会存在很多质量隐患，不要上来就问责测试。
基于当前的研发能力，对未来事故的发生频率给予合理的预期，尤其在上面描述的场景下，这时候，如果还要做大型架构设计改造，那么未来一定会出现各种质量问题，需要对质量问题有足够的容忍度，提供宽松的空间让大家去踩坑，只有这样才是最为人性的处理。
放缓产品交付节奏，缩小产品影响范围，逐步交付，降低事故发生频率。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
测试员就是“背锅侠”？学会这些，扔掉测试人常背的3口“锅”相关推荐
- 测试员≠“背锅侠”：学会这些，扔掉测试人常背的3口“锅”
最近发生了一起生产事故,究其根源,事故本身属于架构或者需求层面需要规避的问题,测试人员的责任其实是非常小的,但实际情况是:相关测试人员因此承担了很大的压力,成为质量问题的"背锅侠" ...
- 华为云大面积宕机的原因思考－谁是下一个背锅侠？
2020年4月10日上午,华为云出现了大面积故障,华为云平台承载了300多万用户,其中160万开发者,影响面积可想而知. 随着云计算技术的飞速发展,企业已经大概率选择上云,随着用户的增加,共有云出现故 ...
- 测试员都是背锅侠？测试人员避“锅”攻略，拿走不谢
最近发生了一起生产事故,究其根源,事故本身属于架构或者需求层面需要规避的问题,测试人员的责任其实是非常小的,但实际情况是:相关测试人员因此承担了很大的压力,成为质量问题的"背锅侠" ...
- 程序员，技术的“背锅侠”，盘点 2020 年面向监狱编程的那些事！
[CSDN 编者按]过去一年,"删库跑路".安全漏洞等事件层出不穷,企业.技术人深受其害,作为一名程序员,在新的一年即将到来之际,我们该如何避免面向监狱编程? 作者 | 马超 ...
- 测试的职责是什么，就是不当背锅侠
测试的目的是什么?就是投入一定的成本人力尽可能的发现软件问题避免发出去给公司带来一定的损失,可以说最大程度的保证软件质量,也是测试的职责.那跟我说的测试职责就是不背锅,有冲突吗?没有,而且是在小步快跑 ...
- 产品经理真的是「背锅侠」吗？
我经常可以看到产品经理们在深夜发出一些激励人心的文字,例如:「由于自己考虑不缜密引发了需求变更,进而导致了开发同学在深夜还在加班敲代码,自己十分自责内疚,不过最后产品还是顺利上线了...」.每每看到此 ...
- 告别运营怪圈，不做“背锅侠+加班狗+低薪族”！
万年背锅侠和加班狗已不再是程序员,而是运营,被毙稿.被客户骂.被领导和同事质疑是普通运营的日常. <2017 年运营行业生存报告白皮书>显示:69.8% 的运营月薪低于 8000--远低于 ...
- 上夜班的linux运维都坑,运维是个坑，盘点背锅侠的点点滴滴~
原标题:运维是个坑,盘点背锅侠的点点滴滴~ 运维是个遇坑.填坑.再遇坑.再填坑,有些时候还被同事挖坑,duang的一下掉下去了,还要自己慢慢爬坑:有些却是自己了解不够深入,或不够细心所留下来的坑. 小 ...
- 或许你就是那个背锅侠【多图】
要说现在哪个岗位最容易招黑,咱们做开发的首当其冲. 产品卡顿偶尔躺枪,产品瘫痪日常中箭, 就连产品注释写错的黑锅都要向咱们砸来...... 开发者们就是行走的背锅侠,哪里有锅哪里背! 今天,我们就来盘 ...
最新文章
- mysql 命令行小结
- spark sql的简单操作
- [leetcode]26.删除有序数组中的重复项
- copying mysql status_mysql慢查询copying to tmp table
- 参考文献自动搜集管理完美攻略（图文版）： Latex+Lyx+Zotero
- 设计师交流社区，在集设原创作品通过交流发现问题，不断进步！
- java解析html_java中几种解析html的工具
- float类型转integer_【第3章：Java基础程序设计】_Java数据类型
- nginx websocket wss 连接失败 failed_浅谈WebSocket协议、WS协议和WSS协议原理及关系
- ＜c++STL＞: map的常见用法
- javascript开发中的封装模式（转）
- 基于单片机和C语言的毕业设计,毕业论文基于51单片机的C语言程序设计实训100例（1）（喜欢就下吧）...
- epub电子书--目录结构介绍
- 老人疯狂裂变引流视频推广微信小程序源码支持定时流量主
- 冯乐乐之二 shader的数学
- mysql 长连接_使用mysql的长连接
- ResNet 残差神经网络（小白版）
- Office：手动卸载 Office 系统
- Word2010撤销按钮失效，Ctrl+Z失效解决办法
- 关于ios的ipa包的分析之link map 文件的分析