质量策略
分析维度
主要分为角色, 流程, 计划和检视四个环节
角色(以下加粗的项均为各角色内部保证自身质量的环节)
内部 : 研发内部各角色如何去保证质量
- 开发 : 编写设计方案, 设计方案评审, 代码审查, 开发自测, 计划评审
- 测试 : 编写测试用例, 用例评审, 计划公审, 测试验证, 交叉测试, 系统测试, 专项测试, 验收测试
- 自动化测试 : 冒烟测试, 深度验证测试, 招投标测试
外部 : 需求, 数据, 分支
- 需求 : 需求评审, 需求交底, 需求验证, 需求验收
- 数据 : 数据自测, 数据互测, 子目变换自动化任务
- 分支 : 分支验收
对于以上质量保证环节, 除自动化测试外, 其余均有质量保证措施. 由于目前的自动化针对Q4产品仅处理跑通当前脚本, 对于软件新的变动导致原有脚本不能覆盖当前新的变动时, 基本采用的是先封掉该验证项的处理方式.故对于当前需要进行自动化任务的版本, 自动化分析时的质量与分析人的个人能力强相关.
对于测试人员而言, 在内部角色中, 需要积极的去推动内部角色的质量保证措施的执行和结果检视, 同时, 对于外部角色, 需要做好沟通和策略的咬合, 并尽量的将测试活动前移到外部角色的质量保证环节之后, 从而尽早发现问题.
举例
比如某地区新发了一套报表
| 环节 | 角色 | 任务 | 测试介入 | 测试输出 |
|---|---|---|---|---|
| 1 | 需求 | 分析 | 拿到原始报表同需求同步进行分析 | 1. 报表业务与当前业务的差异点; 2. 软件需要处理的内容, 包括报表分发及其条件, 数据源分发及其条件 |
| 2 | 需求 | 交底 | 在需求交底会上, 针对测试所分析的内容与开发需求进行确认 | 1. 测试范围;2. 测试入口出口准则 |
| 3 | 开发 | 编码 | 根据测试范围和入口出口准则, 对开发的报表分发配置和数据源配置进行静态测试 | 满足原始需求的开发配置 |
| 4 | 测试 | 测试验证 | 针对报表进行数据动态正确性测试(包括精度, 横平竖平), 报表格式, 报表配套功能, 特性处理点 | 1. 格式正确,出值正确,符合出口准则的报表;2. 报表关联功能冒烟通过 |
| 5 | 测试 | 交叉测试 | 针对前一环节进行确认测试, 确保目标达成 | 衡量测试人员的测试能力, 对测试遗漏点进行统计, 检视测试策略完整性 |
| 6 | 测试, 自动化测试 | 系统测试 | 针对版本整体进行冒烟, 针对新增功能进行探索, 针对软件外围如加密锁,升级,兼容等内容进行测试, 确保版本的有效性 | 输出待验收版本 |
| 7 | 需求, 分支 | 验收测试 | 分析需求分支验收的切入点和问题, 对测试策略和测试版本进行补足 | 输出版本整体缺陷分析及质量评估报告 |
流程
版本研发流程
对于成熟的老产品, 研发流程已经固化, 主要需要考虑计划的时间风险.
时间风险上, 主要有三类:
- 人员能力导致的时间风险: 任务交付延迟
- 流程咬合导致的时间风险: 需求,数据,测试,自动化,开发五方的计划咬合导致的时间风险
- 外部因素导致的时间风险: 市场急切需要版本, 研发全体开会
针对这类风险, 需要做的是:
- 版本初期, 需要对此类风险加以识别和确认. 针对确定项做好应对措施, 针对不确定项, 做好两手准备.
- 过程中加强与各方的沟通, 由于此过程目前还是电话,qq或邮件沟通为主, 耗时且易造成信息不对称, 需要思考如何从形式改变. 目前这一块儿, 自己还在方法探索阶段, 没有啥好的办法.
测试流程
对于测试而言, 当测试团队人员稳定时, 主要需要考虑人员能力带来的风险. 故当新人需要介入版本任务时, 需首先进行能力确认, 即通过对比新人和老人的测试结果来间接的验证当前新人的能力.
针对这类风险, 需要做的是:
- 团队需要积极思考测试方法上的突破, 借助工具来让测试活动变得有效简单且效率高.
- 从计划安排上, 需要根据对应测试资源能力的预估来合理的安排时间. Tips:人员A定级在P3-1, 但若是刚入组, 也需要从小版本往大版本过渡, 只不过过渡时间会相应缩短, 而不是直接就独立负责项目工作.
- 对于测试活动的出口准则, 负责人要严格把关. 同时通过缺陷分析, 来评估当前的测试活动是否达到期望.
计划
主要分为: 时间风险, 人员风险, 执行风险 前两个风险在测试流程中已经描述. 执行风险, 我个人给的定位为:人为因素的导致的风险, 比如粗心, 遗漏, 没想到等等.
针对执行风险, 需要做的是:
- 对入口准则进行细化, 将测试准备以及启动的条件明确清楚.
- 用出口准则来检视入口准则是否有效
检视
从版本整体出发, 需要以用户为中心去进行下面三个关键检视
关键时间点检视
内外部用户何时需要, 此部分与计划咬合一致. 主要用于检视前期计划咬合是否可行, 以及过程中计划调整对关键时间点的影响. 是识别时间风险的重要指标.
关键任务检视
重点难点功能是否达到出口准则, 此部分与目标一致. 主要用于检视重点难点功能的有效性. 是识别人员风险和执行风险的重要指标.
关键指标检视
策略的期望结果是否达成, 此部分与目标一致. 主要是用于检视研发流程和测试流程的执行情况. 是识别版本风险的重要指标.
总结
以上为自己今年对于质量策略上的思考. 部分内容已经经过验证: 比如: 团队需要积极思考测试方法上的突破, 借助工具来让测试活动变得有效简单且效率高, 以此来避免人员风险, 这项内容已经在全数据接口版本上实践, 并取得了很好的效果. 同时, 在测试前移上的思考和实践也验证了文中表格所描述的测试介入是可行的. 但由于业务测试不能深入了解或不关心软件内部实现以及各角色的质量完成情况, 导致测试环节表面问题多且难以归类, 也无法快速定位问题原因和思考解决办法, 造成版本目标模糊(只定bug数为目标, 目标太宽泛), 时间风险较多(开发定位bug较慢, 测试交付延迟, 测试集中在下午才提bug, 开发晚上经常性加班改bug), 影响范围模糊(不清楚具体影响的范围, 常见句型:XX可能会有影响)等一系列问题. 这些问题目前还在思考中, 希望能在明年解决掉这些问题.
