项目需求流程

技术

需求等

流程分析讨论及测试后续规划

Step - 02

  1. 形成需求池(业务需求、技术优化、BUG修复、配合外部方需求)
  2. 输出PRD,并且评审,评审需要全角色:产品、开发、测试(业务方需要参加?);技术改造需要产品知晓和一起评估。都需要评审
  3. 分用户、上下游系统、技术改造&缺陷修复

Step - 01

  1. 需求范围数量需要控制(目的:聚焦工作,做有价值的需求,需求按重要级别和紧急程度2个维度,每个维度中各级别数量控制好),业务方需要内部做需求PK,辨别出真正核心的诉求,建议最好统一一个接口人,对接产品经理
  2. 提前提出需求(一次一个季度的需求一起提?)提前一到二个月,跟产品经理明确(BRD阶段)

Step - 03

  1. 重视评审,问题在评审会上提出/需求讲述不清晰准确,可以驳回(驳回记录\问题)--标准?第二阶段
  2. 重视性能要求,2B端重点关注海量数据查询\汇总\导出,移动端的兼容\性能需求;测试资源(人力、设备、环境等)提前识别
  3. PRD通过,需要明确前端起止时间,后端起止时间,联调时间,明确到模块;测试需要明确测试起止时间;提测节奏

Step - 04

  1. 版本节奏(建议2周一个迭代)
  2. 版本对应分支
  3. 分支对应环境
  4. 版本迭代定义明确,按系统迭代,不是按需求迭代
  5. PMS目前的痛点:按各需求的节奏迭代和排期,导致比较混乱,无全局节奏,人力配比无法做到最优。

Step - 05

  1. 开发设计评审?
  2. 开发单元测试覆盖
  3. 新系统-架构设计评审
  4. 开发与测试配合的模式(Devops)

Step - 07

  1. 产品需要独立UAT,此阶段不包含在测试阶段
  2. 测试提供技术相关支持,业务相关由产品自行解决(考验自身对业务和系统,包括上下游业务的理解和熟悉程度)
  3. 基于迭代版本统一UAT

Step - 06

  1. 测试点分析(内审)、测试用例评审(外审)
  2. 测试过程可追踪,测试记录完备(功能测试记录,性能测试数据记录,其他测试等)
  3. 如何评估测试质量(测试质量度量标准需要建立)
  4. 如何评估项目/需求质量和效率(需求/开发/测试度量维度和标准建立,数据需要搜集)
  5. 固定时间/节奏,发版
  6. 环境管理/分支管理对应,推一版到底,测试的版本即是上线版本

Step - 08

  1. 上线清单:资源/配置/数据/人力/上线验证清单/需要配合平台或系统/回滚方案/回滚后验证方案
  2. 回滚方案中需要明确,需要开发牵头做

业务

需求

产品

需求

需求

评审

版本

计划

开发

阶段

测试

阶段

UAT

上线

方案

线上

监控

Step - 09

  1. 线上监控机制
  2. 线上故障响应流程机制/方案完善(第一响应人\升级机制\处理流程\工具)
  3. 线上问题溯源:测试是否漏测?测试是否有能力发现?开发问题?架构问题?产品问题?线上使用问题?

01. 需求池建立\管理

  1. 需求池规范化管理
  2. 统一明确迭代的定义:以系统版本为横线,需求分期为纵线
  3. TAPD上需求命名规范+迭代命名规范和迭代规范划分
  4. 需求池外的需求,不得流转到开发测试

02. 版本规则建立

  1. 2周一个版本迭代,一个月2个版本,月前提前一周左右确定版本中需求的范围(建议业务需求,技术需求,BUG修复的比例综合考虑)
  2. 版本确定后,原则上不接受任何临时插队需求;宝森同意的,做特殊处理
  3. 所有BUG修复或临时需求,需要在管理平台上跟踪和管理,原则上不接受平台以外口头需求

03. 开发分支管理

  1. 开发设计评审,需要拉上产品、测试,如果上下游关联,需要上下游一起参会评审
  2. 按story提测,做到所提即可测(story功能可以完整走通)

04. 测试环境和节奏管理

  1. 测试产出的缺陷一律平台录入管理,跟需求对应
  2. 测试提UAT,需要产品在UAT环境自行验证
  3. 测试意识需要提升,除业务场景外的,极端场景,比如性能,稳定性/鲁棒性,安全性相关,需要考虑需不需要;全局的场景用例需要丰富

05. 线上故障响应机制

  1. 线上问题跟踪管理:需要统一在平台上做管理和流转
  2. 响应规则建立:需要产出线上故障响应方案,和各业务线响应责任人

第一阶段:短期目标和措施(2020.09-2020.10)

目标:稳节奏、拉通各环节、测试覆盖上线版本

01. 需求评审与管理

  1. 建立PRD标准(需要明确的流程,性能指标等)
  2. PRD全员负责制:全角色评审,尽量杜绝后期变更,PRD评审需要业务方参与和确认
  3. 必要的变更需要走流程,并知会全角色;

02. 开发过程管理

  1. 代码review是否需要测试参加
  2. 开发代码分支管理和策略,对应版本节奏,建议系统一个迭代一个版本

03. 测试标准

  1. 测试用例标准建立(丰富各维度场景用例)
  2. 测试准入准出标准建立和落地
  3. 对应版本和分支,以集成测试环境上的分支为测试重心,测试完成后该版本上预发和生产,中间不做除BUG修复外的代码合入

04. 线上问题优化和复盘

  1. 处理问题脚本/工具需要经过各方评估和检验(产品,开发测试)
  2. 故障复盘一定要有跟因,一定需要明确整改行动项,行动计划和测试人,并作为任务项跟踪

05. 测试工作补齐

  1. PMS主导全场景E2E的用例整理和维护,自动化落地及持续迭代
  2. 测试工作拆分,迭代节奏正常后,补齐接口测试相关工作

第二阶段:短期目标和措施(2020.10-2020.12)

目标:稳夯实基础,修炼基本功

01. 需求评审与管理

  1. 需求评审过程和记录落地,可量化,数据可分析
  2. 项目过程中的需求变更数据落地,可量化可分析

02. devops探索

  1. 逐步落地devops,试行代码门禁,提高提测质量
  2. 提测记录需要可追溯,可实时量化,需要相关数据落地

03. 测试管控提升

  1. 测试用例(功能/性能)执行结果可追溯,可实时量化
  2. 测试用例管理,要脱离为了管理而管理,需要有全局的版本演进节奏和意识
  3. 拉通自动化和devops机制,提高质量验证效率

04. 问题预防

  1. 逐步提升测试业务能力和技术能力,尽早发现问题
  2. 逐步建立测试自己的线上的业务监控(基于核心场景用例)

05. 测试平台/人员培养

  1. 规划和初步落地测试相关的平台和工具(测试数据制造和任务管理等)
  2. 人员培养与全面业务能力提高

第三阶段:中期目标(2021.01-2021.06)

目标:提高测试效率,保质保量交付

01. 质量可度量

  1. 需求质量可度量
  2. 开发质量可度量
  3. 测试质量可度量
  4. 线上质量可监控

02. 持续提升质量

  1. 建立代码门禁规则
  2. 持续推进devops,持续测试,持续交付
  3. 建设测试用例管理平台,实现全类型用例沉淀及迭代优化,打好测试灵魂基础
  4. 落地和持续优化各维度测试方法论,查漏补缺

03. 提升效率

  1. 建设测试管理平台:测试工作管理线上化、自动化;减少重复无技术含量的手工工作;
  2. 落地多维度自动化,提升测试效率
  3. 终极目标:建立测试实时验证,实时结果反馈

04. 测试技术提升

  1. 性能测试能力和调优能力建设落地
  2. 自动化(接口与UI)能提升
  3. 测试平台产品化和方案化

05. 测试前沿技术探索

  1. 基于AI的测试技术探索
  2. 基于测试工程的测试架构探索/测试功能能力建设

长期目标和措施(2020.06 ----)

目标:提升技术,反哺质量效率

阶段一:

夯实基础,明确本职可达的目标

阶段二:

扬帆起航,各方向建立起基本工具和平台,逐步提升技术和业务能力

阶段三:

激流勇进,能力互补形成闭环依赖,技术引领质量

319
4
21
发布时间: 2020-09-07