近期群里，有一個同學在我的軟件質量群里，發出一段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

如果消除了該原因，是否能避免此類問題再度發生

當該原因被消除后，以后此類問題將不再發生，得到徹底解決。

在實際情況中，由于貫徹和執行不力，有些問題不能馬上得到解決，但問題的發生頻率呈收斂趨勢。

最后，宋老師留一道實際案例，大家來看看根本原因是什么？改進措施又是什么？

實際案例分析

有一次，中興收到移動公司的投訴。投訴內容是：中興人員送的設備，放在樓下就走了，沒有送上樓，服務態度不好。于是質量牽頭，副總參加，召開分析會議，物流同事說，我們中興沒有人員送貨，送貨的都是物流公司，所以，根因是：物流公司人員的服務意識不到位和物流部無關。

結果話音剛落，就被我給駁回了，我說：這個問題的根因就是物流部，而不是什么物流公司。

好，同學們，你們贊同宋老師的判斷么？為什么？

要探討的可以在我公眾號（同用戶名）留言哦！！

總結

以上是生活随笔為你收集整理的rust营火为什么放不下去_从一个研发质量案例看，5why分析法，为什么分析不下去了？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。