测试应该对项目的上线时间负责吗？

测试还能评估时间的么

肯定是项目经理负责，如果没有项目经理（小公司），那就是技术部的总负责人负责。
各个模块负责人需要为自己的估时负责，如果时间不够，需要跟项目经理说明可能的风险，由项目经理决策。

严格来说是项目经理的事，时间节点应该项目经理把控。

即便是因为测试部门的原因造成了延误，那么项目经理也应该考虑到可能存在的延误，并及时协调各方沟通并知会，换句话说，理论上，即便测试部门人员有问题造成延误，项目经理也不是可以随意甩掉锅的。

但是，这些都是理论上的，实际上——有时候开发自己还就是测试呢，你怎么办？

现实中一般有两种解决思路。

一个是讨价还价法，就是自己预估了 1 天完成的测试，直接报 3 天，然后通常砍价还价下，也就变 1 天了。记得在相关软件里要有明文存档留证。不然也白砍了。

有的时候会变本加厉，3 天砍 1 天，中途跑过来再砍，说要半天。那这种时候就要注意，砍价要有底线。

还有个注意的点，其实也是本来应该做到的内容，测试是有项目的，不可能就用测试两个字涵盖所有内容。功能列表列个 1-10，写全了，每个分别多久时间，压测要多久，等等等等写明。

然后就变成了讨价还价的时候，你 12345 列出来，总共要多久，告诉对方。比方说往死了压都要 3 天了，对方说不行，那我们只有 2 天，必须上线。

ok，可以，那从中做一些取舍吧，比如说某某功能我们就不测了，能省下时间，但不测可能带来的风险是什么，万一出了风险是否能承受？ 你都要一五一十告诉对方，让对方做取舍，同时做书面留存。

这样除了能按时完成任务，还有个好处，体现出你和对方是站在一起的，是为了结果考虑的，你只是个执行，根据对方要求来执行的，但同时你充分为他着想了。

十有八九对方不敢自己完全做主，毕竟是风险哪，出了问题他那里敢背。但有了你的轻重缓急的列表，他也会和你站在一起，根据你给的建议，继续去向别的人或者领导阐述和解释，不管最后谁定夺，反正一直到有个人愿意为此承担责任才罢休。

所以我上面多次说了，书面留存，书面留存。



但这些套路别以为是职场生存技巧之类的，甩锅指南什么的，说到底，这确实是一种负责人的态度。把轻重缓急相关利弊都列出来，也确实能给别人做更好的决策。

有的时候我看大家都在说，领导根本不懂一个某某小功能有多复杂，领导一句话，下面要做三天，领导只给一天，还不满意，说一天怎么只做了这么个东西出来。

领导不理解是正常，术业有专攻，但我们不翻译下给他听，告诉他某某功能背后可能涉及的逻辑和可能性是什么，那领导怎么知道呢？如何把技术术语翻译成听得懂的人话，这真的是个技术活。尤其是，还要体现出你不是甩锅推卸责任，而是真的为了结果着想。

这些东西学会了也确实不能提高你的专业技能，但学会了这些，大多数情况下你能更有效率更专心的来在工作中提高你的专业技能，还是不亏的，值得一试。

qa，质量保障。推动项目应该是项目经理

要测试对上线时间负责，意思就是你不用测试了，免得发现什么 bug，又要修，哪里有时间修嘛

为了上线时间有时候是可以放弃 bug 的，看问题格局要大些。

如果说绝对准确的上线时间的话，开发测试都给不了。但是可以根据经验评估出个大概时间。我们公司最后的上线时间是测试定的。开发要在开会时自己评估的时间点把功能交给测试。开发逾期或者 bug 太多那开发自己背锅。

测试给测试的排期，时间不够项目经理或项目负责人协调，给出的排期哪些部分可以压缩。实在压缩不了，找上级，是否能放弃一部分，到时候有锅也不是开发或者测试一个人的

所有支持型团队都会有这个蛋疼的问题，明明你能给的就是评估与风险预告，但团队就是要你对结果负责，仅仅因为你是某个下游的环节，上游就能把锅甩得干干净净……