江苏龙网

  1. 首页 > 人文 > >

缺陷管理，一门关于质量内建的学问( 三 )


2.2 生产缺陷流转过程
在生产缺陷发生后 ， 我们会先决定其优先级以及处理流程 ， 然后快速修复 ， 并对其深入分析 ， 其流转过程如下图所示：
缺陷管理，一门关于质量内建的学问
本文插图
3. 缺陷分析
敏捷测试原则说我们应该预防缺陷而不是关注缺陷的数量 ， 所以对于缺陷分析 ， 我们的出发点是：对已发生的缺陷进行深入分析 ， 从中找到问题所在 ， 以达到预防缺陷的目的 。
3.1 分析周期
迭代内缺陷的数量比较多 ， 而且一般大多数都是开发逻辑错误造成的 ， 一般而言分析价值不大 。 如果每个迭代平稳运行 ， 缺陷数量平稳 ， 建议不用特意分析 ， 毕竟分析缺陷是耗时的 。 如果某个迭代明显感觉缺陷数量增长 ， 可以针对性对本迭代缺陷进行分析 。 当然 ， 如果你有充分的时间 ， 可以将缺陷分析作为一项日常工作 。 而对于生产缺陷 ， 每一个都值得被重视 。 2.2节讲述的流转过程 ， 其中我们就已经对其进行分析了 ， 分析其问题出在哪儿 ， 然后补充相应的测试 。 如果想要对生产缺陷进行归类、趋势分析 ， 那么就需要有一定的数据才可以 ， 而生产缺陷不常有 。 所以其分析周期建议是1个月 ， 或者3个月 ， 甚至6个月 ， 视各个项目组的情况而定 。
3.2 分析角度
我们组常用的分析角度有以下几个 ， 不同的项目侧重点会有所不同 。
（1）缺陷根因
可以将缺陷一一分析后进行归类 ， 根因可以分类为：需求缺失或者不清晰、技术方案设计问题、代码逻辑错误、测试未覆盖、环境相关（硬件、软件、第三方等） 。 分类后如果某一类问题较突出 ， 则可以针对性产出改进事项 。
（2）缺陷发现阶段
针对迭代内缺陷 ， 发现阶段可以归类为：故事验收阶段、功能测试阶段、回归测试阶段 。 我们知道 ， 缺陷越早发现修复成本越低 ， 如果分析后发现某一阶段出现的缺陷较多 ， 应该去反思是哪个环节错了 ， 我们是否可以更早的暴露缺陷 。
（3）缺陷所属功能模块
功能所属模块根据系统不同而不同 ， 这一类分析帮助我们思考 ， 某一块存在的缺陷多是因为存在技术债还是测试覆盖不够 ， 可以帮助我们改进质量策略 。
（4）缺陷数量趋势
如果可以 ， 对于迭代内缺陷可以维护一份数量趋势图 ， 就不需要我们靠直觉去感受哪个迭代缺陷多 ， 而是有真实的数据作为依据 ， 更具说服力 。 对于生产缺陷 ， 建议可以维护一份数量趋势图 ， 因为生产缺陷数量走势也是反应我们产品质量的一个重要维度 。
（5）缺陷可识别阶段
这一分类主要针对生产缺陷 ， 缺陷可识别阶段可以归类为：需求分析阶段、开发阶段、测试阶段、发布阶段 ， 难以识别 。 这样分类的初衷不在于归过于某一角色 ， 某一人 ， 而是为了进一步分析是哪一阶段的实践有缺失 ， 需要进一步改善 。
（6）缺陷类型
缺陷类型可以归类为：功能缺陷 ， 性能缺陷 ， 安全缺陷 。 敏捷项目中的QA需要关注产品各个方面的质量 ， 包括性能、安全等 ， 将缺陷类型划分清楚 ， 可以指导补充我们薄弱的地方 。
这些分析维度并不是一开始就是这样的 ， 途中经历过多个版本 ， 有增有减 。 比如一开始我们没有“缺陷类型”这个分析维度 ， 将所有的缺陷都归为功能缺陷 ， 后来逐渐关注平台的安全问题 ， 以及随着平台用户增加 ， 也出现过性能问题 ， 所以加入了“缺陷类型”这个字段 。 又例如 ， 我们一直保持着“缺陷所属功能模块”这个分析维度 ， 而且比较重视该维度分析 ， 因为通过对它的分析常常能发现一些问题 。 所以分析维度不是固定一层不变的 ， 是可以根据项目实际情况择优选择的 。
3.3 分析工具
数据有了 ， 就需要将数据可视化出来 ， 便于分析 ， 便于展示给团队 。 我们项目组曾使用过的分析工具有：


推荐阅读


上一篇：嘉人|行走江湖，怎么能缺少一件超飒皮西服

下一篇：燚燚育儿|“冻龄老妈”穿女儿校服走红，40岁状态依旧青春，网友：女神来了40岁的宝妈成了“校花”在本案例中：40岁的宝妈却活成了20岁的校花宝妈知识小time：产后要怎么恢复保养呢？