项目需求开发流程_技术开发计划_流程图_甘特图
2024-09-09 13:41:47 30 举报
项目需求开发流程_技术开发计划
作者其他创作
大纲/内容
线上监控
目标:
开发阶段
Step - 05
建设测试管理平台:测试工作管理线上化、自动化;落地多维度自动化,提升测试效率终极目标:建立测试实时验证,实时结果反馈
建立代码门禁规则建设测试用例管理平台,实现全类型用例沉淀及迭代优化,打好测试灵魂基础。
Step - 06
形成需求池(业务需求、技术优化、BUG修复、配合外部方需求)输出PRD,并且评审,评审需要全角色:产品、开发、测试(业务方需要参加?);技术改造需要产品知晓和一起评估。都需要评审分用户、上下游系统、技术改造&缺陷修复
04. 测试环境和节奏管理
04. 线上问题优化和复盘
线上问题跟踪管理:需要统一在平台上做管理和流转响应规则建立:需要产出线上故障响应方案,和各业务线响应责任人
Step - 02
开发设计评审?开发单元测试覆盖新系统-架构设计评审开发与测试配合的模式(Devops)
01. 需求评审与管理
05. 测试平台/人员培养
Step - 08
Step - 03
05. 测试工作补齐
测试点分析(内审)、测试用例评审(外审)测试过程可追踪,测试记录完备(功能测试记录,性能测试数据记录,其他测试等)如何评估测试质量(测试质量度量标准需要建立)
PMS主导全场景E2E的用例整理和维护,自动化落地及持续迭代测试工作拆分,迭代节奏正常后,补齐接口测试相关工作
测试产出的缺陷一律平台录入管理,跟需求对应测试提UAT,需要产品在UAT环境自行验证测试意识需要提升,除业务场景外的,极端场景,比如性能,稳定性/鲁棒性。
技术需求等
UAT
业务需求
02. 开发过程管理
测试用例(功能/性能)执行结果可追溯,可实时量化需要有全局的版本演进节奏和意识拉通自动化和devops机制,提高质量验证效率
测试阶段
更多实用干货,点击此处获取
2周一个版本迭代,一个月2个版本,月前提前一周左右确定版本中需求的范围版本确定后,原则上不接受任何临时插队需求;
03. 提升效率
测试用例标准建立测试准入准出标准建立和落地对应版本和分支,以集成测试环境上的分支为测试重心,测试完成后该版本上预发和生产。
上线清单:资源/配置/数据/人力/上线验证清单/需要配合平台或系统/回滚方案/回滚后验证方案回滚方案中需要明确,需要开发牵头做
代码review是否需要测试参加开发代码分支管理和策略,对应版本节奏,建议系统一个迭代一个版本
线上监控机制线上故障响应流程机制/方案完善(第一响应人\\升级机制\\处理流程\\工具)线上问题溯源:测试是否漏测?测试是否有能力发现?开发问题?架构问题?产品问题?线上使用问题?
03. 测试管控提升
Step - 01
Step - 07
阶段二:扬帆起航,各方向建立起基本工具和平台,逐步提升技术和业务能力
02. 版本规则建立
04. 问题预防
04. 测试技术提升
版本计划
需求评审过程和记录落地,可量化,数据可分析项目过程中的需求变更数据落地,可量化可分析
规划和初步落地测试相关的平台和工具(测试数据制造和任务管理等)人员培养与全面业务能力提高
05. 测试前沿技术探索
03. 开发分支管理
开发设计评审,需要拉上产品、测试,如果上下游关联,需要上下游一起参会评审按story提测,做到所提即可测(story功能可以完整走通)
产品需求
产品需要独立UAT,此阶段不包含在测试阶段测试提供技术相关支持,业务相关由产品自行解决(考验自身对业务和系统,包括上下游业务的理解和熟悉程度)基于迭代版本统一UAT
02. devops探索
性能测试能力和调优能力建设落地自动化(接口与UI)能提升测试平台产品化和方案化
上线方案
版本节奏(建议2周一个迭代)版本对应分支分支对应环境版本迭代定义明确,按系统迭代,不是按需求迭代PMS目前的痛点:按各需求的节奏迭代和排期,导致比较混乱,无全局节奏,人力配比无法做到最优。
基于AI的测试技术探索基于测试工程的测试架构探索/测试功能能力建设
阶段三:激流勇进,能力互补形成闭环依赖,技术引领质量
01. 需求池建立\\管理
05. 线上故障响应机制
需求范围数量需要控制(目的:聚焦工作,做有价值的需求,需求按重要级别和紧急程度2个维度,每个维度中各级别数量控制好),业务方需要内部做需求PK,辨别出真正核心的诉求。
处理问题脚本/工具需要经过各方评估和检验(产品,开发测试)故障复盘一定要有跟因,一定需要明确整改行动项,行动计划和测试人,并作为任务项跟踪
需求评审
03. 测试标准
流程分析讨论及测试后续规划
Step - 04
逐步落地devops,试行代码门禁,提高提测质量提测记录需要可追溯,可实时量化,需要相关数据落地
重视评审,问题在评审会上提出/需求讲述不清晰准确,可以驳回--标准?第二阶段重视性能要求,2B端重点关注海量数据查询\\汇总\\导出,移动端的兼容\\性能需求;测试资源提前识别PRD通过,需要明确前端起止时间,后端起止时间,联调时间,明确到模块;测试需要明确测试起止时间;提测节奏
逐步提升测试业务能力和技术能力,尽早发现问题逐步建立测试自己的线上的业务监控(基于核心场景用例)
01. 质量可度量
建立PRD标准(需要明确的流程,性能指标等)PRD全员负责制:全角色评审,尽量杜绝后期变更,PRD评审需要业务方参与和确认
需求质量可度量开发质量可度量测试质量可度量线上质量可监控
02. 持续提升质量
需求池规范化管理统一明确迭代的定义:以系统版本为横线,需求分期为纵线TAPD上需求命名规范+迭代命名规范和迭代规范划分
Step - 09
阶段一:夯实基础,明确本职可达的目标
0 条评论
回复 删除
下一页