章节
概述
1、什么是项目把控
2、关键词
3、说明
前提
1、了解需求背景及业务架框
2、项目需求知识
3、明确需求上线的目标
过程
1、提测前
2、测试中
3、上线后
场景实操
总结
结合QA岗位的个人理解:运用一切手段/方式/方法,保证项目按期按质上线;
按期:根据项目既定的目标时间发布上线
按质:在追求按期的基础上保证原有的质量要求
每一辆项目的火车都不可能原封不动的按计划轨道进行,中间或多或少都会有所偏差,项目管控中允许一定的偏差,这点不需要有心里压力
本次分享没有追求面面具到的覆盖,只是分享一些思路点
有助于对项目整体的定位及规划,如:该项目在公司/部分中的定位、该项目达成对业务的影响度
力求系统化、流程精细化,如:跨业务体系统交互逻辑实现,如果不了解或因前期对业务可实现性评估不足,可能会测到某个节点时发现有问题,而导致出现被卡住的风险
质量&时间目标,没有目标的管控是没有任何意义的
主要思路:了解需求、做计划、不断沟通
1)向前靠:需求前期就尽量的参与了解需求,及技术设计,结合自已的测试经验,排除后面测试中可能出现的风险
2)做计划:针对本次项目需求,做一份具体的执行计划,罗列出相关的人、事、物
3)拜码头:先跟该项目所有干系人打招呼,明确各自分工责任及业务实现
4)拉圈子:将所有干系人拉一起,坐下来聊聊,并将自已的计划同步给大伙
主要思路:灵活多变、敏感细致、沟通
1)合理按排:不能死守计划,测试过程千变万化,应该灵活多变、人员合理安排:如:做生不如做熟的原则
2)阶段推进:将整个项目分阶段推进,每个阶段再细分到具体每天的工作量,如果每天进度达计划进度,整体上也不会有大问题
3)敏感细致:测试过程可能会在测试环境遇到一些不正常/不明白的数据或场景,此时不觉得可能是测试环境不稳定问题,应该敏感起来,怀疑代码/逻辑是否有问题,及时找相关人沟通,避免后续出问题阻碍进度的风险
4)化繁就简:将一些繁杂且重复但已走通的稳定流程通过技术手段集成简单的操作,将大大节省时间
1)跟踪线上质量,确定是否达到质量的要求
2)自我总结:不一定要正式复盘,但一定要自我总结,如本次哪里做得不好,下次应该从哪入手改进
阶段 | 项 | 场景 | 解法 | 备注 |
提测前 | 1 | 测试评估10天,业务方要求7天 | 1、加测试资源 2、砍功能,先保证主功能 3、产品/开发协助测试 4、不砍功能情况下,先测主流程 5、拉长时间并行(一般不建议) 6、加班 | |
2 | 开发不能如期提测,压缩测试工作量 | 1、分批提测 2、提高开发自测率 | ||
3 | 需求并行冲突,2个都是P0 | 1、协调测试资源 2、开发自测 3、没资源情况下保证主流程功能 | ||
4 | 开发冒烟自测前完不成全部测试用例研发自测主流程通过,部分case不通过 | 1、主流程功能不受影响时介入 2、主流程功能阻塞–退回 3、时间允许的情况下,协助造数 | ||
5 | 提测当天需求变动,开发需要改动代码 | 1、产品问题,延期 2、不影响主流程,部分提测 3、暂停需求,先将需求功能点捋清楚,再排期 | ||
6 | 测试资源不足/核心测试中途退出 | 1、要人:新人短时间内测功能性,非强业务相关模块 2、自测 3、卷 | ||
7 | 相关连系统负责人安排不出时间参与评审 | 1、改期 2、评审完,将评审过程纪要,同步群里 3、一对一沟通 | ||
8 | 研发自测主流程不通过 | 1、不介入退回 2、协助造数 3、协助推进沟通(推荐) | ||
测试中 | 9 | 测试中发现bug后,开发一直未改(bug较难改) | 1、摇人推进,产品、技术负责人、业务 2、如果不影响主流程,遗留到迭代解决 | |
10 | 过程发现需求功能实现不了 | 1、摇人推进,产品、技术负责人、业务,改需求/砍需求 2、根据以往经验做方案建议 | ||
11 | 测试过程有其它紧急需求插入 | 1、线上bug,先测 2、优先级别较低,顺排 3、提供用例,开发自测 4、产品/业务定优先级,按优先级来测 5、组内协调 | ||
12 | 测试过程发现评估工作量不足 | 1、加班 2、拋风险 3、将重复性动作自动化,让开发协助造数/定位问题 | ||
13 | 过程各阶段进度与实际计划中的进度相差较大 | 1、先测各模块辊易测的用例 2、拋风险、考虑延期 | ||
14 | 测试快结束时发现产品文档更新过一版,自已的用例不是最新需求文档上的 | 1、写用例前,先让产品更新改动点 2、让产品更新完同步@所有人 | ||
15 | 测试过程,开发重构代码实现 | 1、评估影响风险,是否重新排期 2、建议开发将前置到提测前,或后面迭代实现 | ||
16 | 第三方系统配合响应慢 | 1、穷追不舍@人,长时间没回就电话沟通 2、让项目负责人沟通,可产品/业务,内部可以pmo或上级 3、所有人拉会沟通 | ||
17 | 第三方系统无人力配合测试 | 1、将相关部分功能后置到约好的时间测 2、约好时间,时间要有缓冲 3、摇人 | ||
18 | 沙箱真实数据难造 | 1、抛风险,罗列不可测的场景,商讨是否有解决方案 2、数据构造主流程(分期借钱:目前没有好的解法) 3、长期规划做了沙箱/线上测试数据隔离 | ||
19 | 合并需求/夹带私藏 | 1、拒绝一切有逻辑性改动私藏 2、一般不合并需求,合并需要重新评估时间 | ||
20 | 测试/验收过程,产品加需求 | 1、非必要,不加,放到迭代 2、拉业务/开发一起评估 3、改动量大,评估是否延期 | ||
上线后 | 21 | 出现阻碍主流程的bug | 1、回滚 2、如果有灰度/开关,则关闭,推进灰度数据处理 3、定位问题并回归测试上线 | |
22 | 上线后无法验证 | 1、抛风险,罗列不可测的场景,结合各方建议 2、功能性case验证,观察日志 3、拉长线上数据监控时间 |
项目管控能力说起来就像成功的经验一样,100个人可能会有100种方法,每个人的方式方法运用到自已的身上不一定有效果,但总整上的思路和方向是可以借鉴的
总之,秉承:认真、负责、沟通的态度,基本上事半功倍!
关于作者
林楚葵,深圳业务-金融/上门业务测试组长,主负责团队建设,流程管理,项目管理,测试小组基建能力培养
收录于合集 #测试
24
上一篇