咖啡网站建设,网络搭建教程,很色h做游戏网站,云南机场建设集团网站最近发生了一起生产事故#xff0c;究其根源#xff0c;事故本身属于架构或者需求层面需要规避的问题#xff0c;测试人员的责任其实是非常小的#xff0c;但实际情况是#xff1a;相关测试人员因此承担了很大的压力#xff0c;成为质量问题的“背锅侠”。
实际上#…最近发生了一起生产事故究其根源事故本身属于架构或者需求层面需要规避的问题测试人员的责任其实是非常小的但实际情况是相关测试人员因此承担了很大的压力成为质量问题的“背锅侠”。
实际上测试人员一直处于“背锅侠”的处境今天就来聊聊测试人员究竟背了哪些锅
测试背的第一层锅产品不能如期交付的锅
我们知道产品交付排期一般是固定的很多时候我们在这个基础上进行开发测试排期的倒排而测试作为产品交付的最后一个环节经常被严重压缩排期场景比如
研发未能按时提交测试版本
研发如期交付但功能并未开发完或者交付质量很差。
上述两种场景非常常见尤其是第二种场景这时候测试人员几乎是有口难言人家按时提交了交付质量差也怨不得人家但因此带来很多测试成本原来评估的排期根本不够用。
更有甚者虽然交付测试但部分功能未开发完然美其名曰“敏捷测试”这里不是说敏捷测试不好只不过实际过程中敏捷测试被滥用了因此带来很多测试人力的浪费和排期挤压。
这两种场景带来的直接后果就是测试排期被严重压缩如果产品未能如期交付第一个被拿出来的理由一定是未完成测试。
而为了不背这个锅测试人员只能压榨自己逼自己如期完成。这是测试背的第一层锅产品不能如期交付的锅而为了如期交付测试人员只能压榨自己加班加点。
测试背的第二层锅质量不符合预期的锅
在产品使用过程中如果出现问题第一个被问责的对象就是测试测试人员为什么没有发现该问题
而因为几乎大部分问题都能定性为测试案例未覆盖所以测试经常需要背“质量不符合预期的锅”。
之所以背这顶锅根本原因是业内人员对测试人员的职责定位有误。
大部分人认为测试的职责就是为质量负责且是负全部责任只要是质量问题测试就需要承担起来。
但请问质量是测试出来的吗显然不是质量是设计出来的。
一个坏透了的架构设计注定产品质量会漏洞百出测试无法穷尽所有场景发现所有问题。一个好的架构设计在设计层面就规避掉了几乎所有潜在风险。
当一个产品漏洞百出时一定是架构设计的不够合理这时候无论怎么测试质量都不会太好因此当问题出现时不应该去问责测试为什么没有发现而是去反思架构设计。
总结来说很多时候测试成了架构设计不合理的背锅侠。
当然这个结论的前提是这个问题的确是架构的问题。如果出问题的是核心流程测试的确需要承担一定责任毕竟基本功能需要确保无问题。
测试的职责是验收产品主要功能满足要求。
测试背的第三层锅紧急出版本的锅
很多时候需要紧急出版本修复问题这时候测试排期几乎被严重压缩。然后测试还要担着交付后质量无问题的责任这两者其实是互相矛盾的存在为了保障质量需要充分的时间去测试而排期被严重压缩几乎没时间充分测试测试人员深陷其中苦苦挣扎。
总结来看
一方面产品交付前测试排期被严重挤压测试需要加班加点去完成测试而由于排期被压缩测试可能无法充分展开存在质量隐患。
另一方面产品交付后如果真的出现质量问题测试又会成为第一个被问责的对象而为了紧急修复问题测试又需要加班加点去完成测试而这时候测试周期往往被严重压缩无法充分测试进而又埋下了质量隐患。
这不是“背锅侠”是什么
如果团队研发能力很弱且对交付质量要求很高或者事故容忍能力很低的时候测试面对的压力会被急速扩大成为“超级背锅侠”。
为什么呢因为研发能力弱代表潜在质量问题会很多测试复测成本非常大且交付的产品从根上就注定了功能不稳定导致事故频发。如果这时候产品对事故的容忍能力很低那么后果就是测试需要频繁的被问责以及被要求完成紧急版本的测试。这种情况下压力被严重放大。
如果产品对质量问题的容忍度较高那么测试人员暂且还可以承受住这个“冤屈”而如果团队研发能力很弱且对交付质量要求很高或者事故容忍能力很低的时候就需要考虑“伸冤”了。
如何伸冤
列举几条
摆正测试人员的职责范围质量是设计出来的不好的设计一定会存在很多质量隐患不要上来就问责测试。
基于当前的研发能力对未来事故的发生频率给予合理的预期尤其在上面描述的场景下这时候如果还要做大型架构设计改造那么未来一定会出现各种质量问题需要对质量问题有足够的容忍度提供宽松的空间让大家去踩坑只有这样才是最为人性的处理。
放缓产品交付节奏缩小产品影响范围逐步交付降低事故发生频率。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
