找回密码
 会员注册
查看: 194|回复: 0

需求项目管控的关键-QA的视角分解

[复制链接]

2

主题

0

回帖

7

积分

新手上路

积分
7
发表于 2024-9-20 08:52:50 | 显示全部楼层 |阅读模式
概述     1、什么是项目把控     2、关键词     3、说明 前提     1、了解需求背景及业务架框     2、项目需求知识     3、明确需求上线的目标 过程     1、提测前     2、测试中    3、上线后 场景实操 总结Part1概述1、什么是项目把控?结合QA岗位的个人理解:运用一切手段/方式/方法,保证项目按期按质上线;2、关键词按期:根据项目既定的目标时间发布上线按质:在追求按期的基础上保证原有的质量要求3、说明每一辆项目的火车都不可能原封不动的按计划轨道进行,中间或多或少都会有所偏差,项目管控中允许一定的偏差,这点不需要有心里压力本次分享没有追求面面具到的覆盖,只是分享一些思路点Part2前提1、了解需求背景及业务框架有助于对项目整体的定位及规划,如:该项目在公司/部分中的定位、该项目达成对业务的影响度2、项目需求知识力求系统化、流程精细化,如:跨业务体系统交互逻辑实现,如果不了解或因前期对业务可实现性评估不足,可能会测到某个节点时发现有问题,而导致出现被卡住的风险3、明确需求上线的目标质量&时间目标,没有目标的管控是没有任何意义的Part3过程1、提测前主要思路:了解需求、做计划、不断沟通1)向前靠:需求前期就尽量的参与了解需求,及技术设计,结合自已的测试经验,排除后面测试中可能出现的风险2)做计划:针对本次项目需求,做一份具体的执行计划,罗列出相关的人、事、物3)拜码头:先跟该项目所有干系人打招呼,明确各自分工责任及业务实现4)拉圈子:将所有干系人拉一起,坐下来聊聊,并将自已的计划同步给大伙2、测试中主要思路:灵活多变、敏感细致、沟通1)合理按排:不能死守计划,测试过程千变万化,应该灵活多变、人员合理安排:如:做生不如做熟的原则2)阶段推进:将整个项目分阶段推进,每个阶段再细分到具体每天的工作量,如果每天进度达计划进度,整体上也不会有大问题3)敏感细致:测试过程可能会在测试环境遇到一些不正常/不明白的数据或场景,此时不觉得可能是测试环境不稳定问题,应该敏感起来,怀疑代码/逻辑是否有问题,及时找相关人沟通,避免后续出问题阻碍进度的风险4)化繁就简:将一些繁杂且重复但已走通的稳定流程通过技术手段集成简单的操作,将大大节省时间3、上线后1)跟踪线上质量,确定是否达到质量的要求2)自我总结:不一定要正式复盘,但一定要自我总结,如本次哪里做得不好,下次应该从哪入手改进Part4场景实操阶段项场景解法备注提测前1测试评估10天,业务方要求7天1、加测试资源2、砍功能,先保证主功能3、产品/开发协助测试4、不砍功能情况下,先测主流程5、拉长时间并行(一般不建议)6、加班2开发不能如期提测,压缩测试工作量1、分批提测2、提高开发自测率3需求并行冲突,2个都是P01、协调测试资源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出现阻碍主流程的bug1、回滚2、如果有灰度/开关,则关闭,推进灰度数据处理3、定位问题并回归测试上线22上线后无法验证1、抛风险,罗列不可测的场景,结合各方建议2、功能性case验证,观察日志3、拉长线上数据监控时间Part5总结项目管控能力说起来就像成功的经验一样,100个人可能会有100种方法,每个人的方式方法运用到自已的身上不一定有效果,但总整上的思路和方向是可以借鉴的总之,秉承:认真、负责、沟通的态度,基本上事半功倍!关于作者林楚葵,深圳业务-金融/上门业务测试组长,主负责团队建设,流程管理,项目管理,测试小组基建能力培养收录于合集 #测试 24个上一篇tapd数据本地化管理
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 会员注册

本版积分规则

QQ|手机版|心飞设计-版权所有:微度网络信息技术服务中心 ( 鲁ICP备17032091号-12 )|网站地图

GMT+8, 2024-12-26 00:21 , Processed in 0.400766 second(s), 26 queries .

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表