如果一个项目需要30天，开发每多花一天进行自测，测试的工作量就能少一天的话，或者说开发少在自测上花费一天，测试就要多测试一天的话，那么不管开发自测不自测，项目总时长是不变的，讨论的焦点就是如何分配工作量，由于"公认测试不创造价值"，则开发不自测，而测试时间拉长。
所以对于开发不想花费时间测试的想法我是理解的，所以测试时间的长是很多时候是分担了开发的原本需要做的单测和自测，说测试时间过长有测试效率低的现实，也有目前分工方式的因素。
实际情况是通过代码审查、开发自测能够花费1天的时间减少2天的测试时间，从上帝的视角来看，项目的交付时间因此缩短，应该是有益的举措。大家都说，有益的事情是原本不需要推动的，但是为什么推动开发改进质量那么困难，是因为从开发看来，自身的效率因此下降，而没有觉察什么益处；而测试则觉得对质量有帮助，大力推进。
PM（产品经理和项目管理）、开发、测试的三权分立有其现实存在价值，开发承担着进度压力需要拼命赶需求，测试承担着质量压力需要保证版本质量，而PM协调资源并对进度和质量进行取舍。而在一些项目中，并没有配备专门的产品经理和项目管理，通常可能由开发leader兼任，三权分立容易变为开发和测试的二元冲突，进度和质量的争论往往没有定论或是质量向进度妥协。
质量向进度妥协并不存在对或错的问题。之前在鹅肠搞微信红包的时候，系统就是几个开发通宵开发出来的，质量可想而知，然后边测试边给线上打补丁，开发也遗留了大把技术债撑到了第二年再花时间重构，成为了公司业务突破奖的产品，再后来从微信红包团队诞生了微信支付部门。如果测试人员只关注于质量本身，而不是项目，目光就过于狭隘了。按标准执行对大多数人来说比较容易，但灵活变通就很难了，对于一个有风险的项目，说NO很容易，说PASS很难，首先要把控风险，出了事要承担责任，就像我以前跟新人说的：测试往往要牺牲自己，成就项目;但测试的价值不就应该体现在项目和产品中么，而不只是BUG数字。
不仅是测试，如果开发也能从项目整体的角度上理解自己的角色，我相信研发流程一定会很顺畅高效的。然而这世界上明白事理的人毕竟还是太少了