rust营火为什么放不下去_从一个研发质量案例看，5why分析法，为什么分析不下去了？...

近期群里，有一个同学在我的软件质量群里，发出一段SOS信息。

写不下去了，有没有擅长软件质量根因分析的丫，求指导？

其他编不下去了，哈哈！！

同学以为为了应付客户写的8D报告，在办公室做这编报告呢。但经了解其实也不是啊。很快这位同学，抛出了一段分析过程。

1.问题阐述

产品上线后，客户发现预约页面无法翻页。

2.问题分析

2.1.直接原因

测试过程未发现该问题。

2.2.根本原因

1why：为什么测试过程未发现该问题？

—-原因1：测试组测试遗漏。

-——-原因2：开发组和产品组未对该项进行测试。

2why：为什么测试组测试遗漏？

-———因为测试工程师编写用例遗漏。

我把这段分析，抛到其他群里，希望大家帮这位同学分析一下。

结果大家，还真沿着这个思路做下去了，纷纷开讨论，为什么测试未发现该问题了。

我一看这架势不对了，赶紧出来提示，这个问题直接原因真是 "测试未发现该问题"吗？

不少同学，立马回过神了，发现这个分析的方向性错误了。

首先看缺陷产生的机理

传递途径：Error →defect →fault /failure

Error：执行或计算等未符合规定要求

Defect：错误隐藏在产品中，即形成缺陷

Fault/Failure ：产品终止规定功能，称为故障或失效；如果产品可以修复称为故障，否则称为失效。

我们可以得出推论：

1、问题的根因一般情况在“缺陷的引入点”，如：产品、流程设计缺陷、工艺技术缺陷等等。

2、问题的根因一般情况不会在“缺陷的控制点” ，因为它不是问题发生的源头。

3、只有当“缺陷的引入点”质量无法控制或在能力范围之外时，必须依赖控制点来进行约束，这时“缺陷的控制点”才会构成问题的根因。如来料问题：来料质量问题公司内部是无法控制供应商源头的，只能通过TQC管理和来料检验控制的方法来进行约束。

我们回到上面案例问题，可以知道，把直接原因定位为，测试，明显不属于 引入点，因为质量，是设计出来，不是测试出来的，测试只是对缺陷的识别是缺陷控制点，而不是产生此缺陷的原因。

于是，提出问题的这位同学，继续去调查原因，后面反馈几条关键信息：

1、这个软件是他们供应商做的。

2、缺陷的引入阶段时在编码阶段，原因是 web前端表格控件使用的是第三方，但分页不好用，开发人员自己编写了一个分页器，忘记把控件自带的分页代码去掉了。

大家会发现，根据这些信息，路转峰回。这个问题，符合推论第3点，必须依赖控制点，也就是自己测试工程师来进行约束。

所以，我们从这段过程，会发现，描述清楚问题是进行问题根因分析的重要前提。

因此呢？从 自己测试未发现该缺陷，也是合理的。

那么如何把5why推进下去呢？

原来的推理路径：为什么未对该项做测试导致泄露？-->测试工程师编写用例遗漏

一下将原因归结为测试工程师写漏了，最后只能说，能力不足，培训提升了。但显然这样的分析结果，和很多敷衍性报告一样，推进改进没啥意义了。

其实这里有问题的。

质量讲究过程方法，在问题推导时也需要从过程着手

从过程角度分析看，上述5个因素控制不当，都可能导致测试用例列表出现泄漏

1、需求规格本身漏了；

2、设计方法未采用最佳实践；

3、人员能力，通常不具备设计此用例的知识；人员态度和疏忽，通常没有对应的奖励惩罚措施；突发性外部刺激影响。

4、程序流程是否存在问题或者没有执行，比如是否要求设计完，要先找研发，产品来进行评审；

5、衡量标准，比如要求设计用例，是否有要求，覆盖率要达到100%，还是只覆盖关键风险，是0缺陷标准，还是投入产出比标准。

因此，直接从用例遗漏，就推断为，人员问题，显然是不合理的，会漏掉很多可能因素。5why，应该是从各因素，追查，然后一一排查此推论是否合理，然后排除。

这样分析产生的对策，是基于控制出发，但对供应商是否就真不可控了呢？

其实也不是，对供应商的管控，除了可以对交付物进行抽检外，还可以对其关键过程提出管控要求。

这点在汽车质量体系16949，体现比较明确，对供应商除了产品交付绩效，还需要供应商的过程绩效，比如，不良质量成本，超额运费，达到一定的目标。

因此，我们还是可以对供应商出问题的过程增加管控要求控制缺陷引入点，提出要求可以作为采购合同部分来进行约束和管控。

如果按这个思路，问题的根本原因是，甲方自己，没有对供应商的代码实现过程提出明确的要求，比如，单元测试，或者 同行评审，CI/CD，测试覆盖率要求，都可以有效降低这类风险。因为，供应商只会遵守约定的要求，如果没要求，可以采用自己认为合适的过程方法来交付产品。

好，具体采用哪种方式，其实这就是在上一篇质量计划中需要考虑的问题。也就是，这供应商的质量管理策略。需要判定，风险有多大。如果，风险不大，通过测试验收就可以。如果感觉不靠谱，需要增加对其关键过程的要求，然后在交付时，需要其提供对应的评审或者测试记录，如果核实作假，在验收环节发现，可以加重处罚来提高对方的违规成本方式改善。实际上很多科技公司对供应商的管控，已经在多年前就强调实时在线监控数据申报，比如对芯片过程，还有，Cisco、中兴、华为对外部供应商的过程控制中经常都会用此类方法，管结果，也管过程。可以，大大提升供应商交付产品的质量。

最后，那么如何判定，分析出来的根因是根因呢？下面提供一个checklist给大家，每一项都是的情况下，通常就是根本原因了。

序号

检查项

说明

1

在逻辑上是否是问题原因链的源头或关键因素？

在逻辑上是问题原因链的源头（缺陷引入点）

如果多个原因在逻辑层次上相同，则取关键的原因。如果缺陷引入点在能力范围之外，找缺陷控制点

2

在逻辑上是否能够被识别？

根本原因应该是客观的、具体的、可度量的原因

3

该原因是否能够被纠正？

在目前的组织能力下，该原因可以被改进

对原因的解决不能超出组织可承受的成本

4

如果消除了该原因，当前问题是否得到解决？

当该原因被消除后，当前出现的问题即得到解决

5

如果消除了该原因，是否能避免此类问题再度发生

当该原因被消除后，以后此类问题将不再发生，得到彻底解决。

在实际情况中，由于贯彻和执行不力，有些问题不能马上得到解决，但问题的发生频率呈收敛趋势。

最后，宋老师留一道实际案例，大家来看看根本原因是什么？改进措施又是什么？

实际案例分析

有一次，中兴收到移动公司的投诉。投诉内容是：中兴人员送的设备，放在楼下就走了，没有送上楼，服务态度不好。于是质量牵头，副总参加，召开分析会议，物流同事说，我们中兴没有人员送货，送货的都是物流公司，所以，根因是：物流公司人员的服务意识不到位和物流部无关。

结果话音刚落，就被我给驳回了，我说：这个问题的根因就是物流部，而不是什么物流公司。

好，同学们，你们赞同宋老师的判断么？为什么？

要探讨的可以在我公众号（同用户名）留言哦！！