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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2400 天前的主题，其中的信息可能已经有所发展或是发生改变。

如题。昨天和人争论了这个事情。

我的观点认为，测试只能对质量保证负责，只能给出来到上线时间这个节点的时候，上线风险大不大，无法保证到了上线时间就一定能上线包括，测试评估时间的时候，无法保证开发修改 bug 的时间

不知道是我这么认为的比较偏激还是确实应该这样

上线

测试

保证

时间

9 条回复 • 2018-05-27 19:45:41 +08:00

kindjeff

2018-05-27 11:21:54 +08:00 via iPhone

测试还能评估时间的么

Hieast

2018-05-27 11:24:39 +08:00 via Android

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

ibegyourpardon

2018-05-27 11:36:54 +08:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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