人事数学很好 鉴定完毕

测试就是点工了，还要求 bug 数，有没有 bug 在测之前谁知道有多少

定这个规则的人不懂测试 不懂研发 凡是拿数量去做度量的 一律按照流氓处置

这个逼着开发写 bug 呀

没太理解这位朋友为啥会这么考虑呢？不管是对开发还是对产品，出 bug 对他们利益都不能算是正向利益吧？

开发的核心利益应该是通过完成功能的开发，交付系统给业务产生价值
产品的核心利益应该是通过设计具体产品细节体验，通过交付出去的良好产品产生业务价值

出了 bug，开发的交付会出现延期，产品的体验也会打折扣，这两个都会影响他们的核心利益，少一些 bug 对他们应该是利大于弊的。所以没明白为何你上面的推理为什么会显得好像没有 bug 后，开发、产品价值就受到很大影响？

提到共建。我认为最重要的一点是共识，没有共识，谈什么共建呢，那么共识一定是有共同的目标，有共同的目标前提是有个人的利益。
现在问题来了，共同的利益在哪里？
开发的利益：0bug，根本没有工作量，老板会认为事情非常简单
产品的利益：0bug，那就不能反复折腾了，一门是一门
测试的利益：0bug，那测试可以很本分交付一个高质量产品
可见，当你去细分这个利益时候，发现这张饼显然并不是利益共同体，反而让开发和产品承担了下游风险。所以，共识很难形成，就算形成，也很难落地，所以你提到的共建，其实很难。

对于这个场景太熟悉不过了，在大公司也算是常见了，深有体会。
1、外网出现了 BUG，第一反应不是解决问题，是马上拉测试进群，让测试复现。
2、测试复现出来了，开发和产品质问测试之前版本有吗，用上个版本看下，让测试回溯版本。
3、回溯出来确认了 bug，开发质问之前测了吗，为什么之前没有发现。
4、测试承认漏测，开发马上拉 leader 进群，向产品 Leader 汇报，测试之前没跑到。
5、给出结论：因为测试没有跑到，所以这个问题出现了。
6、for 循环回到第一步。
7、总结：测试不行。
那么，谈到解决之道，其实是整个团队或者说整个行业都存在这样的风气，国内功能测试对于过程质量的把控力度太弱，导致在最后外网复盘环节，更没有话语权了，因为国内产品对于质量目标的认同，却不对过程目标的认同，这是最割裂的认知层次和方向不同，这是测试赛道的悲哀。

没看懂，搞那么复杂干嘛，人事没事干了？

是真匿名的，后台是无法查询是谁的，管理人员也查不出。

我能说我没看懂吗，我算法不好

罚款？ 赶紧跑路吧

高度的责任心，必须享有同等的待遇