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