如果出问题，是谁背责任？难道是测试？

太理想了。现实是：

1. 老板的钱是有限的。
2. 20% 的人创造 80% 的价值，大部分人都是工具人。
3. 相比开发，测试工具人更多。

从老板的角度来看，测试如果连质量都不能保证，那你的专业性在哪里？
如果你不能改变质量，但是你可以尝试用你专业的方法和语言来报风险啊。
不改变自己，别人怎么会被你改变？
你自己不卷起来，你怎么可能卷的动团队？

主要是现在测好了都有赏，出 bug 了测试背锅

为什么开发人员不喜欢自测，不做单元测试的根本原因就是因为他们理所应当的认为有测试进行把关，所以不用太过早担心质量问题！

感谢认可和肯定，呵呵😊

我想表达的是，在一个团队中，软件的质量结果并不是由测试人员独立承担的，如果有这种想法的话，
1.测试人员很难驱动或者把控项目风险，因为测试介入的时间总是晚的
2.项目的过程中其他人员对项目质量职责就会做的不到位，而自己还没有意识

你的想法在测试同行来看是对的，测试对质量负主要责任，但不是全部责任，这个应该大部分同行是认可的。

但怎么改变开发、产品乃至老板的看法，这才是关键。

我觉得对于兄弟团队来说，核心是怎么让他们能把控好自己这块的质量同时，不至于太加大他们负担（毕竟这不是他们岗位的核心工作职责，这个一定要认清），所以我们才常说 “质量赋能”；

至于老板，他的核心是你要保障不能出大问题造成非常大的损失，否则你就没啥存在意义了。所以你得说清楚保障质量是系统工程，而你要做好这个系统工程，目前还存在什么阻碍（比如开发甩手掌柜或者不给测试前期介入开发阶段），这些阻碍曾经造成了什么后果，进而让老板帮助你清理阻碍，来更好地帮助你保障不出问题。

6 楼完美诠释了这个问题~
楼主想法没毛病，其实项目中的其他人也许也是认可这个说法的，只是从利己角度选择了让自己好过一点的说法罢了

你思考问题不能只站在测试的角度。
比如从我的角度来看，测试在我做的项目中没有存在的价值，所以我这几年都不要测试。
但这不代表测试不能在偏业务方向的项目中发挥自己的作用。

让别人相信测试，首先得相信你，通过你去改变别人对测试的认知，这才能解决问题。

什么是质量？
没有页面 BUG 叫质量，24 小时崩溃也是质量。
KPI 怎么定的，技术如何引导的？公司资源多少，你能支配的资源多少？
都是问题，一句话领导不支持，所以我不做了。这样也太简单了。。。
你去要求开发小兵去提升质量就是搞笑，质量得从上到下推，合理的程序设计，规范化的代码设计，通过这些才能大幅解决，但这些不产生直接价值。。。

天天堆业务，堆人，质量能好就见了鬼了。如果这种情况下，只能依靠人工去点，点不出来找点点点背锅不要太正常。你找开发背锅，开发第二天跑了。找你背锅，培训成本低，爱走不走，你是老板你找谁背锅？至少也得一起背吧。

我又学习了，感谢

1、高质量的软件，是设计出来的。依靠测试去保证，太晚。
2、质量永远是第一位的。不要陷入 一些 “政治正确” 的陷阱，诸如：“按时交付，XXX 对质量负责...”
3、按时交付低质量的产品：政治正确，但属于短视行为，长期等于自杀
4、责任与权利对等，跟利益/回报挂钩：
1）彪悍团队，可以左渗右渗到每一个环节，就像基地组织，敢对每一起事件负责。
2）优秀团队：见招拆招，能够快速地分析和溯源出质量问题的本质，建立有效的防范纠错机制。不该我负责的绝不背锅，该我背锅的也要找个垫背的。
3）普通团队：爱咋咋地，活总要有人干，锅总得有人背。通常被一句 “测试为什么没有测试出来？” 直接怼死

5、项目管理、过程管理、流程规范，甚至论坛里的各种自动化框架/工具/平台... 所有的一切都是手段，不是目的。
6、目的：提供价值。

“责任与权利对等，跟利益/回报挂钩” 对于测试在团队中提高影响力，很有帮助，感谢分享

早点转行吧，测试在哪都注定 “位低钱少责任重”