Java教程

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

本文主要是介绍14、时间紧,工作量大,作为测试应该怎么办,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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

描述:主题:时间紧,工作量太大,作为测试该怎么办?

处理方案:

  • 整体评估,定好优先级:项目紧急发版来不及实现全部功能可以三方协商(产品,开发,测试)整体评估,定好优先级进行开发,最好需求评审时就提出来
  • 确认排期时间,分配开发时间、测试时间,明确上线时间
 
  • 与产品沟通确认
    • 与产品确认对质量的期望。(是要求 主流程没问题 还是 页面无重大BUG)
    • 了解上线后的实际场景,是否有真实用户使用
    • 提出目前所存在问题:时间紧,任务重,人员不足
    • 提出/申请方案:加人,或砍需求(延期)。都无法做到则明确测试质量不一定会很好,主流程能通,但是会有存在一些问题
    • 设计产品验收提前介入验收,方便后续UI变更不影响发版时间
 
  • 与技术对接确认:
    • 是否可以提前提测/大的模块拆分提测,最好不要一次性提测,看看能不能有部分先行提测,缓解各端压力
    • 多了解看看他们开发工作中是否遇到了什么难题,在预期提测日之前了解开发是否能如期提测/提前提测 
 
  • 测试资源调配
    • 单人测试:看看其他组内有没有空闲的测试小伙伴,与老大反馈测试紧张,需调配资源
    • 组内多人测试:合理平均分配好测试工作
 
  • 测试相关:
    • 测试用例上尽量编写优先级最高,高,中的用例/测试点,尽量覆盖到可测的测试点;
    • 借助一些手段/工具尽量在测试之前就把测试数据准备好
    • 测试遇到不可测的情况立刻找开发解决,推不动找项目负责人和产品
    • 及时记录体验问题和暂不改的问题汇总,提交产品排期
 
  • bug提交相关:
    • 提交BUG时,分优先级:优先级 严重、高、中级别的直接开给开发;优先级低的问题开给产品,让产品决定是否需要延后,如果这个迭代需要修复,再由产品转给开发 
    • bug描述:一定要描述清楚,节约时间。客户端:界面位置,接口请求情况;服务端:对应接口请求数据,返回数据。
    • bug太多出现返工,及时找负责人解决,别拖到临近发版
 
  • 进度推进:
    • 进度一定是要产品来推进的,测试也是主力;产品来推进这个进度,测试只是辅助推进 
    • 测试推进点:
      • 优先级最高:提测项是否可以在预期时间提测
      • 其次:
        • 每日关注新增需求点
        • 每日新增bug
        • 每日开发未修复的BUG
        • 测试未验证的BUG
        • 每日新增风险项
        • 关注成员进度反馈情况,严重问题情况。
        • 严重风险项、问题情况及时反馈上级
 
  • 工作态度相关
    • 组内测试成员情绪安抚鼓舞:对组内测试小伙伴进行一些肯定与鼓舞,让大家乐观面对这些情况,尽量以微笑面对她们
    • 高强度 & 紧张的迭代过程中,一定要多多鼓励/赞美开发,理解并肯定开发们的工作。
    • 在这种情况下,大家都很急,千万不要一直催进度,没有任何意义,因为已经挤不出什么时间,别人也会不舒服,大家都互相理解,看看自己有没有能够帮助到他们的,然后先把当下的困难一起解决
 
  • 后续避免/减少情况复发
    • 下次有新的项目了,有新的需求了,要跟产品说,一定要先把需求给开发&测试过一遍,让你们看看大概的排期大概是什么时候 

这篇关于14、时间紧,工作量大,作为测试应该怎么办的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!