敏捷研发流程版本1.0，测试实践指南

这是模板水印，可删除

开发就绪

发起人：Story开发主责人参与人：产品、开发、测试干系人1. 开发对Story的内容进行演示，产品、测试、UI、对功能实现和UI进行验收2.开发主责人把PO验证过程中发现的问题登记在WIKI中。3.开发主责人对验证问题修改完后提交产品验收4. 验收通过后产品主责任发送验收报告给敏捷团队，测试进入测试产品验收1、产品对开发提交的故事进行功能实现和UI实现进行验收2、发布验收记录，明确验收结论3、验收通过后进入测试阶段；未通过验收修改后重新提交验收

产品走查

拆分

发起人：产品参与人：产品干系人及UI前置时间：迭代(n-1)1.需求文档必须完整才能进行评审；2.按照需求优先级评审；3.以原型为基础，需求文档为补充；不清晰的需求在完善并和相关人确认后才能进入开发阶段；4.原型和需求文档需要满足设计规范

名词定义：用户故事（需要添加用户故事点数）：功能类用户故事和非功能类用户故事①功能类用户故事：即开发的软件功能②非功能类用户故事：技术预研、性能优化、技术债清理、框架优化独立任务（不添加用户故事点数）：例行会议、培训学习、支持面试这类事务，对客户和用户而言，没有价值感知 

发起人：产品经理参与人：开发、测试、需求前置时间：需求文档迭代n-3天发出1. 明确需求内容进行业务交底2.进行交底的需求必须经过需求评审3.需求交底范围中明确优先级及业务主场景4.以原型为基础，需求文档为补充

发起人：产研侧参与人：产研侧人员、实施团队人员准出标准1.全量自动化脚本通过率100%2.业务主场景冒烟测试通过（自动化未覆盖部分）

需求交底

迭代N+1(上线发布阶段)

评审记录表

实施UAT预验收

迭代0（迭代启动准备阶段span style=\

PO验证完成/产品验收

发起人：产品经理参与人：产品经理、业务方代表、项目经理1. 产品经理梳理业务方需求、背景 ；2. 产品经理将需求录入到jira的需求池中；3. 产品经理需与相关技术负责人初步沟通需求是否可实现4. 产出概要需求说明书及详细需求说明书

发起人：Master参与人：敏捷团队成员1.A/B/C类问题修改完成，DE类问题产品判断不修改可以遗留2.当前模块由测试人员判断处于较稳定及稳定状态3.缺陷回归通过率100%4.迭代资料文档归档

迭代总结会

每日晨会

发起人：产品主责任参与人：产品人员、敏捷团队成员准入标准1.主功能研发完成且均处于较稳定及稳定状态2.无A/B/C/类严重问题3.自动化冒烟及场景通过率100%输出物：1.产品走查表100%通过2.产品判断需修改问题修改完成3.产品走查问题泄漏分析

需求评审一次性通过率

测试中

交叉测试完成

Master开启Sprint：填入总人日及改进目标

发起人：实施侧参与人：敏捷团队成员、实施团队人员准入标准1.全量自动化脚本通过率100%2.缺陷增量回归通过率100%3.增量业务的验证通过率100%4、需求判断修改的问题全部修改完成输出物测试用例100%通过实施UAT预验收缺陷完成实施UAT预验收问题泄漏分析

客户生产环境发布

发起人：项目管理侧参与人：客户侧代表、实施团队人员准入标准1.自动化冒烟及场景脚本通过率100%2.业务主场景冒烟测试通过输出物1、性能测试报告2、UAT测试报告3、UAT问题泄漏分析4、UAT问题答疑

发起人：Story交叉测试人员参与人：测试1. 输出交叉测试报告(测试进度，稳定性、风险评估)；2.兼容性测试通过3.缺陷复测通过率100%

研发池梳理（Backlogs梳理）

计划会

发起人：Master参与人：开发、测试、需求1.用户故事分拆及补充信息2.链接的史诗故事(Epic)3.故事点数：评估用户故事点数

研发完成

迭代1~迭代N（迭代研发阶段）

发起人：Master参与人：敏捷团队1.明确任务范围（Must，Should）及优先级2. 调整完成的工时分配3. 按照任务优先级及依赖关系，综合评估，校验story的提测日/到期日4. 统计迭代中相关人员节假日/请假/培训情况5. 共识风险，任务(技术+方案)、管理(进度+质量)两方面，并制定跟踪责任人

子任务拆分列表开发主责人【前端】详细设计【前端】详细任务开发xx【前端】详细任务开发xx【前端】联调自测【前端】PO验证/产品验收 【后端】详细设计【后端】详细任务开发xx【后端】详细任务开发xx【后端】联调自测【后端】PO验证 /产品验收测试主责人【测试】测试点分析【测试】测试点评审【测试】测试用例设计【测试】自动化脚本编写调试【测试】自动化脚本评审【测试】迭代测试【测试】交叉测试

发起人：Story测试主责人参与人：测试1. 每日输出测试报告(测试进度，稳定性、风险评估)；2. 自动化冒烟及场景脚本执行通过(按需进行)3.已修改的缺陷复测通过率100%4.兼容性测试通过(浏览器需支持：Edge和谷歌；移动端需支持：安卓和IOS操作系统)发起人：Story开发主责人参与人：开发、测试1.A/B/C类问题修改完成，DE类问题不能遗留>5个进入交叉测试阶段

客户UAT验收

发起人：Story开发主责人参与人：产品、开发、测试开发详细设计1.流程图、数据库、接口文档更新开发业务反交底（产品、开发、测试）1. 由研发按功能点讲述需求的理解与技术实现方案；2. 产品确认研发对需求理解是否一致；3. 研发对各个技术实现方案提出意见或建议并最终达成一致；发起人：Story测试主责人参与人：产品、开发、测试测试点设计1.测试点分析、测试用例设计测试点评审（产品、开发、测试 ）1. 按业务流程进行用例的评审；2. 产品、研发、测试、确认对需求理解是否一致测试用例评审（敏捷小组测试b style=\

开发中

每日站会流程：1. 每天上午9：20准时召开站立会议(特殊情况除外)；2. 会议由团队成员轮流组织，总时间控制在15分钟以内(特殊情况除外)；3. 项目组成员按照人员进行逐个检视，要求简明扼要，每人2分钟，需要包含以下两方面内容：    (1).当前整体进度，在的问题/风险；    (2).今日计划，进度目标，需要的资源支持；晨会规范：font color=\"#1976d2\

需求方案详细设计

发起人：Master参与人：开发、测试规则1.子任务拆分流程类子任务：系统会默认创建一部分迭代流程的子任务，只需要进行认领和估时即可业务类子任务：需要单独进行创建，描述清晰并进行估时2.工时预估工时预估：按照子任务开发完成时间进行估时；相同模块的开发设计时间和测试设计时间可以合并到一个用户故事中，其他用户故事中子任务对应删除3.填写子任务到期日、PO验证时间到期日：子任务到期日按照时间开发时间进行填写PO验证完成时间；【联调自测】+4h4. 优化类型需求进行产品验收，验收后发布验收记录。新研类型需求按照现在PO验证方式进行

拆分子任务

发起人：Story测试主责人参与人：测试1. 测试点执行完成后测试点归档到飞书中2. 测试用例执行结果更新到用例中，执行完成后归档到飞书中3.测试过程中遇到阻塞问题及时同Master或对应主管沟通解决

需求评审

需求排期

发起人：Master参与人：敏捷团队成员1. 回顾目标2. 评估结果3. 分析原因4. 总结经验5.输出下个迭代改进目标项6. 项目复盘过程与结果资料存档

主责人：Story开发主责人参与人：产品、开发、测试1、把当日待办的任务放入开发就绪中，表示当前的用户故事已具备开始研发的条件

发起人：研发经理参与人：产品及master前置时间：迭代n-5天1. 确认迭代范围及边界2. 创建用户故事由研发经理进行粗估故事点数3. 用户故事分配敏捷小组4. 用户故事指定主责研发和测试

测试完成

分拆用户故事

紧急需求要求：紧急需求定义：高优先级、且需要紧急上线的需求。紧急需求可不用严格按照以上流程执行，但要严格控制紧急需求的频次。由产品经理发邮件给项目经理及各负责人，邮件中必须对以下5点进行说明：(1) 需求方(运营、产品)是否已经达成一致?(2) 比起在下个版本里上线，能产生哪些收益?(3) 方案上是否已经明确?(4) 可行性和工作量上是否已经进行过评估?(5) 影响的范围、以及可能存在的风险。审批通过后的紧急需求才能投入开发。其他要求：1.项目进行期间如果有事请假的，需要确保把手上的工作交接给明确的交接人、不影响项目的正常推进，并在项目群里通知到项目组全体成员。需求变更：对于已经排期的需求业主方要求进行变更的，须由项目经理提交需求变更单经业主方签字盖章确认，变更产生的费用由业主方承担

确认关键时间点

开发完成

发起人：Master参与人：开发、测试、需求1)确认用户故事优先级及依赖关系2)确认用户故事提测到期日：PO验证完成日期3)确认用户故事到期日：PO验证完成日期+交叉测试完成时间

发起人：Story开发主责人参与人：研发经理、架构师、开发干系人，不少于2人代码审查（按需进行）:1. 代码审查记录2. 代码审查问题修改完成发起人：Story测试主责人参与人：测试自动化脚本编写1.冒烟用例CheckList抽提2.冒烟用例脚本编写3.冒烟用例脚本执行通过100%开发自测通过自测标准通过率100%测试提供的用例通过率100%开发提供的用例自测执行记录

发起人：产品参与人：相关产研负责人1. 确定需求的优先级；2. 确定迭代计划(版本计划，版本需求，版本起止时间)；3. 每个版本进行一次需求排期；输出：1)创建版本2)创建业务场景Feature3)创建史诗Epic4)JIAR中添加相应模块

业务解决方案