一个 sprint 测完后有一些遗留问题，不发版影响业务交付，发版这些问题上生产就影响测试的考核
所以，这个发不发版测试人员如何衡量？
问 po 就说，他的原则是必须在不影响交付时间的条件下，所有修复后才能发版。但是实际情况不可能这么顺利。
问研发组长，就说修复没问题，给时间。
最后的结果就是甩给测试，你来决定发还是不发
最后再郑重说明下：本部门大佬非常看重需求交付时间，跟业务约定的时间，不能影响交付。还要求测试严格把控质量。认为线上的问题都算测试的。整个一个大杂烩。
就造成一个现象：测试想严格把控质量。其他方赶紧走交付，反正生产问题测试背锅。
测试报告写明，测试不通过，如果需要上线就走豁免上线，把锅甩给 PM
你们公司测试还能决定发布不发布，如果你能决定，就不发了
你在纠结什么啊？肯定不发啊，延期就延期呗，是问题影响的又不是没测完，这种情况你才应该是最强势的好不好
顺不顺利的和你有啥关系，交不交付又与你何干，你干完你该干的了，剩下的自有人背，自信点，你现在可以随意催他们了，底线就一个：必须保证修复后的问题回归时间
谁是领导啊，这不得 测试 研发 PM 共同决定啊
领导会去承担责任？还不是底层打工仔来承担，拿你当枪使啊
不发版那能叫遗留问题？
所有的决定都应该是遵循大家都同意的规则去判断的。比如发版前是否还有哪个等级以上的缺陷，剩余的缺陷是否拿到业务的同意，可以接受这些缺陷在以后再修复。
如果目标是按时发版，那就以达到发版目标去提前规划，以及每天的日报里面把这些写出来：改修复的赶紧修复，不能修复的赶紧找业务商量，拿他们的背书。如果最后还是有严重的缺陷没办法处理完，业务也不同意上线，那就别上了呗，反正测试我就不松口，谁要违反流程去上，那就是谁的锅。
所以最根本的，还是要把相关负责人拉到一起，把这个游戏规则讲明白；统一规则之下，谁违反谁的锅。测试不能轻易降低自己的标准，这样也不会轻易被甩锅给测试。
另外再说一句：对于测试来说，我们的责任是质量把控，所以能不能按时交付，不归我们管，我们关心的是质量能不能达标。当然了作为团队的一分子，我们也要对交付时间做贡献，保障测试效率，按计划内时间完成测试；遇到开发延误的情况下，大部分情况下还是要尽力去配合赶上进度。 但原则还是质量标准不能降低。
发了有问题算你的，不发跟你有什么关系，咋拎不清呢。。。
有些事不上秤没四两重，上了秤一千斤打不住
好多 sprint 项目都没有 pmo，项目管理的角色由 PO、RD 组长或 QA 组长的任意一方兼任。
单听描述感觉你们项目太乱了：PO 是又要马儿跑还不给马儿吃草，RD 是得吃草才能跑，最后马儿跑不完就赖 QA 鞭子抽的不够狠，这不扯吗。
及时的把风险同步出来，必要的话每天发个日报同步 bug 修复进度，再不行就抄各方领导甚至拉会，总之这个锅不能无缘无故落 QA 头上。
论立好规矩的重要性
有锅一起背，大家都同意发，那发，有锅你背，那锅就在那等着你呢，发啥啊。