常用质量工具-鱼骨图.pptVIP

目录 奋斗的青春 绽放的精彩 常用质量工具-鱼骨图 甘小玲 1 鱼骨图（因果图、石川图） 鱼骨图由日本管理大师石川馨博士提出，又称石川图。 它是一种发现问题根本原因的方法，也可称为因果图。 鱼骨图的特点： 结构化的分析方法，便于快速识别问题产生的原因； 可视化，促进沟通和理解。 问题 原因类别 原因类别 原因类别 原因类别 一层原因 二层原因 一层原因 二层原因 一层原因 二层原因 二层原因 一层原因 二层原因 使用步骤 寻找疑因： 使用“头脑风暴”寻找问题的可能原因 将找到的疑似原因写在卡片上 疑因亲和： 使用亲和图法对寻找到的疑因根据其相关性进行聚类，进而得到问题分类和部分一层原因、二层原因 将亲和的结果填入鱼骨图 疑因追加： 针对亲和得到的原因分类，再次运用头脑风暴，在之前的基础上补充可能的一层原因； 结合5why方法，进一步寻找可能的二层原因，三层原因等。 末端原因要具体明确，能直接采取对策。 确定问题分类： 可从如下维度考虑： 5M1E：Man（人）、Machine（机器）、Material（材料）、Method（方法）、Measure（测量）、Environment（环境） 组织结构/人员角色：开发、测试、维护 关键字：如对于汽车，考虑安全性、外观、价格、售后等 确定主疑因： 从所有潜在原因中，选择主疑因。 选择主疑因的过程是对问题和原因的理解达成共识的过程，建议不超过5个。 主疑因从末端原因中选择。 使用步骤 NO YES ０准备 １画图 ２确定问题 3 原因类别清晰？ 3.2.1 确定原因分类 3.2.2 寻找疑因 4 确定主疑因 5 必要信息记录 ３.1.1寻找疑因 3.1.2 疑因亲和 3.1.3 疑因追加 结束 自下而上(小骨集约) 自上而下（大骨展开） 使用步骤 准备：组织者要提前准备讨论和记录可能需要材料，比如白板、白纸、便签纸等。 画图： 初始化鱼骨图结构，依次画出鱼头（结果）—主干—原因分类 具体原因分类的数量可根据讨论情况进行补充 案例1 继承性测试时间长 测试用例 测试环境 框架自动化率低 测试用例可执行差 测试用例冗余 测试用机不够 搭建环境时间过长 测试人力 测试管理 人员安排不合理 测试策略不合理 开发支持原因 开发定位不及时 测试人力不足 测试员对业务不熟 自下而上（小骨集约法，适合原因类别不清晰的场景 ） 人力不足 没有提前识别风险 框架自动化率低 测试用机不够 开发支持原因 测试策略不合理 搭建环境时间过长 测试用例可执行差 人力不足 开发支持原因 没有提前识别风险 测试策略不合理 测试用机不够 搭建环境时间过长 框架自动化率低 测试用例可执行差 测试环境 测试用例 测试人力 测试管理 测试用例描述不清 测试用例预期结果不对 开发定位效率低 没提前识别风险 缺乏进度跟踪方法与工具 控件交互不符合 测试 开发 设计 测试用例未包含UI规范 未提供UI规范给测试人员 UI规范难以转化为测试用例 认为UI规范重要性低 缺少UI方面的验收标准 UI问题分散在各模块易漏测 测出的UI问题未跟踪 最初UI问题未提问题单 缺少对交互效果的UI说明 高保真原型效果缺失/有误 UE未掌握控件交互要求 认为UI规范写作意义不大 UI规范写作费时 UI模板中需UE补充内容过多 高保真开发人员不理解控件交互规范 控件交互的UI规范无宣传/培训 无可借鉴的控件交互规范 控件交互的UI规范无宣传/培训 实现难度大 工作量大 UE未能检视出高保真上的错误 UI规范对交互效果说明有误 UE对控件应有的交互效果理解有误 对UI规范的掌握不全 开发工作量大 某些单控件交互开发工作量大 多模块同控件重复开发 分工开发，无人进行控件交互统筹 认为UI开发重要性低 控件无积累，开发从零开始 前期未估算UI开发工作量 开发人员未应用UI规范 UI规范可操作性不强 未掌握UI规范的内容 控件开发完才提供UI规范 无UI规范应用的宣传 缺少培训/宣传 自上而下（大骨展开法，适合原因类别较清晰的场景） 案例2 案例讨论 自下而上（小骨集约法，适合原因类别不清晰的场景 ） 讨论：为何项目版本质量较差？？ 学习材料不够系统 全员质量意识薄弱 人员复用率低 测试 能力弱 团队沟通不畅 学习材料过少 AAR、质量回溯效果不佳 质量目标未进行全员宣讲 质量流程规范难落地 质量奖惩措施未严格执行 关键质量评审环节把关不严 需求流程不畅 一线SA能力薄弱 江西、陕西流程响应慢 研发流程不符合项目轻流程要求 新人多 团队氛围建设 会议多，效率低 知识地图刷新不及时 模块田未更新 SVN路径乱 紧急需求插入多 版本节奏不符合客户需求 接口人不明确 质量活动未例行展开 会议冗长、制定时