本文章出自【码同学软件测试】
码同学公众号：自动化软件测试
码同学抖音号：小码哥聊软件测试

提起“压工期”这三个字，相信没有人比测试人员更能深刻体会了，这三个字一直在我们的工作中挥之不去，如影随形。

笔者曾经历两周时间压成一周，一周的工期压成两天的项目。也经历过压根就没有考虑测试时间，上线时间一固定，开发完了剩多少时间就有多少测试时间的情况。
那么，既然事实如此，我们能做些什么呢？我们秉着3W的原则来分析一下。

WHO 谁压了我们的工期？

测试人员作为项目流程中的后置流程，自然是前置流程压缩了我们的工期。前置流程有谁呢?产品和开发，项目组分得细一些，就是产品、前端和后端，每个流程都延期了一点，上线日期却保持不变。那么给测试小伙伴留的时间自然是少的可怜。

WHY 为什么会被压工期？

我们看看前置流程为什么会被延期。首先看产品，产品延期说明需求出了问题，需求问题大致可分为两种：一、需求不完整或需求出的晚；二、需求变更频繁。这两种情况在项目中也许因为各种各样的原因无法避免，但是一旦没有一个好的应对措施，将会对项目产生很大的影响，最可能出现的情况就是质量不佳+项目延期。 再来说开发，开发除了需求原因导致的延期以外，最可能出现的情况是需求分析不透彻，开发时不考虑细节，旁支的业务点没有考虑到，导致提测后出现的bug可能会出现很大的工作量，甚至可能会推翻之前的设计。

WHAT 我们能做什么？

笔者根据这些年的项目经验，以上问题都遇到过，这里分享一些解决方案：

1.需求不完整或得出较晚

就我个人的经验而言，关于需求有两种项目模式是对项目成员来说最舒服的。

一种是固定上线日期。要求本期项目开始前，需求范围及细节已经准备得很充分。也就是说产品经理需早早得将需求整理好，本期开工第一天可以做需求评审及分析。开发和测试按照需求分析结果估算工期，保证如期完成任务并及时提交给下游流程。

另外一种是非固定上线日期。当需求完成的日期不确定时用这种模式。以需求评审的那一天为本周期的第一天，按照各个环节的工期推算出上线日期。

需要注意的是，以上两种模式都需要产品一次性将需求整理完整，并且每个环节不允许延期。如遇到延期情况，则项目上线日期延期。

免费领取 码同学软件测试 课程笔记+超多学习资料+完整视频+最新面试题，可以转发文章 + 私信「码同学666」获取资料哦

2.需求变更频繁

“需求变更”这四个字大概是最让开发头疼的了，也是最常见的开发延期原因。针对这一点，产品经理需要做的是认真评估需求紧急性。按照优先级判断是否需要马上做需求变更。如不需要，变更内容可放到下期迭代；如确实需要本次完成，则调整其他需求或调整工期。

3.开发对需求分析不透彻

除开发自身要提升自己的分析能力外，作为Teammate，我们要做的是，做好每一次的评审，包括需求评审、开发设计评审以及测试用例评审。每一次的评审都是一次梳理需求的过程，每个可能被开发忽略的小的需求点，我们都可以在评审时提醒他。评审不仅仅是对当前作业的检查，更多的是为了使团队中每个人的信息对等，查缺不漏，是一个互补的过程。此外，我们在梳理需求时都会有一些产出，如脑图、流程图等，这些产出我们都可以分享出来，来帮助大家更好的理解需求，以避免遗漏的问题在测试阶段才被暴露。

4.开发无法专心做事

其实写代码和写文章一样，都需要一段清净的时间，集中注意力，方能文思泉涌，如有神助。而开发真实的工作场景通常是，文思正在泉涌，却被屡屡打断。开发过程中总被各种人要求查各种问题。这些问题有的是看似严重的生产问题，有的是其他关联项目的联调问题。它们不一定是bug，却来势汹汹，一个比一个急。而作为测试，本身比开发更熟悉业务流程，凭借对业务的了解和技术的支持，我们完全可以首先过滤这些问题，给开发腾出一个干净的工作时间。

免费领取 码同学软件测试 课程笔记+超多学习资料+完整视频+最新面试题，可以转发文章 + 私信「码同学666」获取资料哦

总结

也许有很多测试小伙伴看了上面的话，会觉得这些东西跟我们做测试的没什么太大关系，这些都是产品、开发，或者是团队管理者需要提升或者考虑的东西。然而这里我想提醒伙伴们的是，往大了说，我们是一个team，团队中的每一个件事我们作为队员都有责任去做；往小了说，我们作为流程中的后置，前置流程顺顺当当不是刚好可以解决我们被压工期么？ 从团队的角度出发，化身砖头，哪里缺人补哪里。毕竟，帮助团队就是帮助自己。

最后分享一下我自己在测试岗位上做过的事：

1.无论工期多紧张，都坚持写测试用例（抱怨没时间写的小伙伴可以看我之前的文章《敏捷模式下的测试用例该如何存在》）
2.每次拿到新需求从开发的角度考虑如何更节省时间成本的实现最好的结果，并给出建议，帮助开发更快速的理解需求
3.梳理需求时出的思维导图和流程图分享给团队
4.遇到产品没有考虑到的问题时，分析原因及成本给出解决方案建议
5.当开发因其他原因无法专心做新功能时，及时给予帮助（如查生产问题，我们可先过滤问题，分析原因，解决非bug的问题）
6.平时遇到困难多思考，复盘时将团队的问题提出来，与大家讨论最佳方案去实施
7.提升自己，帮助队友，共同成长。

你永远比你想象得更优秀。
也许今年开始得比每年更困难些，但是，有个词叫做“好事多磨”。

笔者跟大家分享一个福利！扫码回复【csdn码哥群】入软件测试自学交流群，可免费听技术讲座+领学习资料+视频课免费看

作者：码同学软件测试
本文著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。