14、时间紧，工作量大，作为测试应该怎么办

描述：主题：时间紧，工作量太大，作为测试该怎么办？

处理方案：

• 整体评估，定好优先级：项目紧急发版来不及实现全部功能可以三方协商（产品，开发，测试）整体评估，定好优先级进行开发，最好需求评审时就提出来
• 确认排期时间，分配开发时间、测试时间，明确上线时间

• 与产品沟通确认
• 与产品确认对质量的期望。（是要求 主流程没问题 还是 页面无重大BUG）
• 了解上线后的实际场景，是否有真实用户使用
• 提出目前所存在问题：时间紧，任务重，人员不足
• 提出/申请方案：加人，或砍需求（延期）。都无法做到则明确测试质量不一定会很好，主流程能通，但是会有存在一些问题
• 设计产品验收提前介入验收，方便后续UI变更不影响发版时间

• 与技术对接确认：
• 是否可以提前提测/大的模块拆分提测，最好不要一次性提测，看看能不能有部分先行提测，缓解各端压力
• 多了解看看他们开发工作中是否遇到了什么难题，在预期提测日之前了解开发是否能如期提测/提前提测 

• 测试资源调配
• 单人测试：看看其他组内有没有空闲的测试小伙伴，与老大反馈测试紧张，需调配资源；
• 组内多人测试：合理平均分配好测试工作

• 测试相关：
• 测试用例上尽量编写优先级最高，高，中的用例/测试点，尽量覆盖到可测的测试点；
• 借助一些手段/工具尽量在测试之前就把测试数据准备好
• 测试遇到不可测的情况立刻找开发解决，推不动找项目负责人和产品
• 及时记录体验问题和暂不改的问题汇总，提交产品排期

• bug提交相关：
• 提交BUG时，分优先级：优先级 严重、高、中级别的直接开给开发；优先级低的问题开给产品，让产品决定是否需要延后，如果这个迭代需要修复，再由产品转给开发 
• bug描述：一定要描述清楚，节约时间。客户端：界面位置，接口请求情况；服务端：对应接口请求数据，返回数据。
• bug太多出现返工，及时找负责人解决，别拖到临近发版

• 进度推进：
• 进度一定是要产品来推进的，测试也是主力；产品来推进这个进度，测试只是辅助推进 
• 测试推进点：
• 优先级最高：提测项是否可以在预期时间提测
• 其次：
• 每日关注新增需求点
• 每日新增bug
• 每日开发未修复的BUG
• 测试未验证的BUG
• 每日新增风险项
• 关注成员进度反馈情况，严重问题情况。
• 严重风险项、问题情况及时反馈上级

• 工作态度相关
• 组内测试成员情绪安抚鼓舞：对组内测试小伙伴进行一些肯定与鼓舞，让大家乐观面对这些情况，尽量以微笑面对她们
• 高强度 & 紧张的迭代过程中，一定要多多鼓励/赞美开发，理解并肯定开发们的工作。
• 在这种情况下，大家都很急，千万不要一直催进度，没有任何意义，因为已经挤不出什么时间，别人也会不舒服，大家都互相理解，看看自己有没有能够帮助到他们的，然后先把当下的困难一起解决

• 后续避免/减少情况复发
• 下次有新的项目了，有新的需求了，要跟产品说，一定要先把需求给开发&测试过一遍，让你们看看大概的排期大概是什么时候