如何建立高效的品質保障機制

前言

這篇文章實際上構思了很久,如標題所述:如何建立高效的品質保障機制。

在之前無論是寫文章還是工作實踐,在品質保障機制方面也有大量心得,但總覺得缺點什麼,直到前幾天寫了項目交付系列的幾篇文章才豁然開朗。

之前關注的視角大多還是從測試或 QA 角度出發,但如果從項目角度的全局出發,反而可以將很多的實踐經驗串聯起來,形成體系化的東西。

這篇文章,我想和大家聊聊,關於建立高效的品質保障機制,我自己的一些認知和想法。

 

思維導圖

 

 

如上圖所示,我個人理解的高效品質保障機制,由下面幾點構成:

品質把控:需求品質+過程品質+交付品質;

項目落地:通過不同的項目來達成品質保障的核心:風險可識別+問題可追蹤+結果可驗證+數據可量化;

交付能力:持續迭代+持續集成+持續發布+持續運營+持續度量(用戶和業務是不斷變化的,交付能力也要持續跟進);

標準體系:工程方法+工程系統+專業團隊(用專業的團隊,採用業內成熟的軟體工程方法論來指導工程系統落地演進);

品質文化:品質+效率(先保障最終品質可控,再提高過程效率,通過節省下來的資源去投入到提高品質的實踐和迭代);

 

品質把控

關於品質把控,我在前面的文章《復盤歸因,提高交付品質的秘訣》中已經做過詳細的贅述,這裡摘取部分內容。

從品質保障和交付的角度來講,軟體交付生命周期中大體可分為如下三個階段:

需求設計品質

這個階段包括原型圖、PRD文檔、交互設計、技術方案、測試用例等重要產出物,當然他們有一定的前後依賴關係。

為什麼需要做大量評審工作呢?因為如果在源頭存在問題,那麼研發過程和後面的用戶使用品質,就無從談起。方向錯了,就全錯了。

評審最大的作用就是集各個角色(產品&研發&測試)從不同角度對需求設計進行解讀理解,提出疑問和建議並進行修正。確保開始就確定方向和需求細節,儘可能降低或者避免遺漏及不合理帶來的品質交付風險。

研發過程品質

「軟體品質是構建出來的,不是測試出來的」。

測試的本質是驗證研發交付的產出物是否達到需求設計及預期的標準。並不能直接帶來品質的提升,只能通過種種手段多維度去驗證是否達標,並通過流程規範、度量標準等去保障最終的交付物達標。

因此我們常說的各種測試手段,都是驗證和保障交付品質的手段,而不是構建品質的手段。

交付用戶品質

用戶品質指是軟體上線後,對用戶使用過程進行追蹤並採集數據進行評估度量的過程

常見的評估維度有線上缺陷逃逸率、客訴工單、用戶回饋建議、數據埋點等。

 

項目落地

這裡提到項目落地,含義是指通過技術項目來保障上述三點品質把控能更好的完成。

我在之前的文章《測試工程師的職場發展二三談》中聊過流程對品質保障的價值:風險可識別+問題可追蹤+結果可驗證+數據可量化。上面的思維導圖中介紹的五個模組,他們的作用分別如下:

獨立項目

獨立項目的作用是支撐上述的從需求到交付的過程品質可以很好的進行保障,提前識別存在的風險。

常見的獨立項目,大家可以理解為我們常見的造數工廠、單元測試、自動化測試等技術項目。

環境治理

環境是我們開展一切測試工作的前提,也是最底層的基礎設施,因此環境的穩定性是至關重要的。

但隨著業務、技術以及人的不斷變化,環境的穩定性越發的成為部分企業技術團隊特別是測試團隊面臨的巨大問題。

關於環境治理,具體可參考我之前的文章:《被忽視的問題:測試環境穩定性治理》。

監控告警

基於不同環境,我們需要搭建完善的監控告警和日誌體系,作用是為了更快的識別過程品質中出現的種種問題,並且能做到快速跟蹤定位,然後進行修復優化。

還有一點作用是,對問題的可視化展示和記錄,有助於後續的復盤歸因,讓問題的發生得到收斂。

覆蓋率平台

談起覆蓋率,我們可能會想起很多名詞,比如:單元測試覆蓋率、自動化測試覆蓋率、測試用例覆蓋率等等。擴展一下甚至還包括線上缺陷逃逸率。那覆蓋率的作用是什麼?

脫離數據講品質是空中樓閣,我們從各種不同的維度去評估覆蓋率,至關重要的一點就是多維度的評估和驗證過程品質。

品質大盤

如何理解品質大盤?即從需求品質到交付品質整個周期中,將每個階段的要做的事情,出現的問題,發生的風險以及結果都進行可量化的記錄展示,然後從中進行分析評估,找到不足之處。

品質一定要可量化,品質度量的本質是具體的定量,而非抽象的定性

 

交付能力

無論是保障品質,還是通過獨立項目或者技術手段來支撐品質保障,都需要持續的某些能力來支撐他們。

這些支撐橫向交付的流水線能力,主要包括CI持續迭代-CI持續集成-CD持續發布-CO持續運營-CM持續度量。

持續迭代Continuous Iteration)

一般來說我們日常工作中的需求,都是通過不斷的迭代來持續打磨產品,不斷為用戶提供更好的服務和價值。

這裡的持續迭代,更多指的是業務或者需求上的一種可持續的變化。

持續集成(Continuous Integration)

持續集成可以幫助技術團隊更加頻繁的將程式碼更改合併到共享分支或”主幹”中。一旦對應用所做的更改被合併,系統就會通過自動構建應用並運行不同級別的自動化測試(通常是單元測試和集成測試)來驗證這些更改,

確保這些更改沒有對應用造成破壞。這意味著測試內容涵蓋了從類和函數到構成整個應用的不同模組。如果自動化測試發現新程式碼和現有程式碼之間存在衝突,CI 可以更加輕鬆地快速修復這些錯誤。

持續發布(Continuous Deployment)

這裡的持續發布包括持續交付(Continuous Delivery)和持續部署(Continuous Deployment)。

完成 CI 中構建及單元測試和集成測試的自動化流程後,持續交付可自動將已驗證的程式碼發布到存儲庫。持續交付的目標是擁有一個可隨時部署到生產環境的程式碼庫。

在持續交付中,每個階段都涉及測試自動化和程式碼發布自動化。在流程結束時可以快速的將應用部署到生產環境中。

對於一個成熟的 CI/CD 管道來說,最後的階段是持續部署。作為持續交付的延伸,持續部署可以自動將應用發布到生產環境,持續部署在很大程度上都得依賴精心設計的測試自動化。

持續部署意味著開發人員對應用的更改在編寫後的幾分鐘內就能生效(假設它通過了自動化測試)。這更加便於持續接收和整合用戶回饋。

總而言之,所有這些 CI/CD 的關聯步驟都有助於降低應用的部署風險,因此更便於以更快的節奏發布對應用的更改。不過,由於還需要編寫自動化測試以適應 CI/CD 管道中的各種測試和發布階段,因此前期建設需要很大的資源投入。

持續運營(Continuous operation)

上面聊到了持續集成、持續交付和持續部署,應用在生產環境發布後,需要持續的跟蹤線上品質、用戶回饋建議以及線上可能發生的一些問題或者故障。

所有線上的用戶建議、可能發生的問題或者故障,其實從本質來說,和交付品質都息息相關。因此這裡提出了持續運營,就是提倡品質的把控、驗證、度量即使到了生產環境,也需要持續不斷的將這套機制運行下去。

持續度量(Continuous measurement)

還記得上文中提到的關於覆蓋率和品質大盤的內容me?

脫離數據講品質是空中樓閣,從需求品質到交付品質整個周期中,將每個階段的要做的事情,出現的問題,發生的風險以及結果都進行可量化的記錄展示,然後從中進行分析評估,找到不足之處。這是個需要持續投入的過程。

品質一定要可量化,品質度量的本質是具體的定量,而非抽象的定性

 

標準體系

前面我們介紹了需求保障的三個要素,支撐需求保障過程的項目支撐能力以及橫向的持續交付能力,但這些都脫離不了標準的體系化支撐。縱向的組織標準化體系,需要工程方法+工程系統+管理機制+專業團隊來兜底。

工程方法:即採用業內成熟或者前沿的軟體工程方法,來指導這些底層技術工作的開展。

工程系統:工程系統,既包括我們上面提到的CI/CD等基礎技術設施,又包含環境治理、監控告警甚至日誌管理等。

管理機制:管理是個很複雜的問題,這裡我試圖借用我之前關於測試流程的一些理解,為大家提供一些視角。

流程是什麼?

流程是保障團隊目標達成的最佳實踐,因人/團隊/業務類型/迭代速度/資源緊張程度而異。

為什麼要有流程?

沒有流程會導致團隊中的個體各自為戰,目標不統一,進度不協調,資源配給失衡而導致交付品質下降。

流程能解決什麼問題?

流程能保障團隊或者群體在大方向上保持協調一致,儘可能降低由於團隊人員能力、認知水平、資源不足、意外情況導致的項目延期或者品質下降。

專業團隊:無論是工程方法還是軟體工程系統,甚至品質度量和品質運營,都需要專業的人來做這些事。

綜合來說,標準的組織體系,最大的作用是通過實際校驗的技術工程建設來保障底層

 

品質文化

在軟體品質保障領域,品質文化概括來說就四個字:品質+效率。

品質,就是在日常交付中保障軟體品質,並且在長期發展過程中,不斷提高軟體的品質。如何評估品質是否是穩定且不斷提升的,就需要引入評估體系,用事實、結果、背後的分析邏輯和數據來證明。

效率,就是提高效率。怎麼提高效率呢?引入ROI體系,從交付時間、耗用資源、團隊成長方面著手。

有了文化,還要將其拆分為不同的目標。行業在變,組織架構在變,因此目標也要跟隨整體的變化而調整。

當然,品質文化是需要不斷強調和落地的,這就需要制定一些規則來保證文化的落地效果。這裡的規則不是強制要求大家一定要做什麼,而是為了避免某些方式對團隊不好的影響。常見的規則比如:資訊同步機制、回饋機制。

談到文化這一塊,一直是很務虛的東西,很多同學對之嗤之以鼻,2020年之前我也是這麼想的。

20年讀了一本書:《重新定義公司:Google是如何運營的》。裡面對企業文化這一部分做了很經典的解釋:企業文化就是指導員工面臨艱難選擇時,做正確的選擇。

 

內容總結

這篇文章,整體的邏輯在開篇的思維導圖就已經很明確進行了概括總結。

建立品質保障文化,通過縱向的組織標準化體系來建設底層的技術基礎設施和持續的流水線交付能力,這些能力可以支撐具體的項目落地,而這些項目對需求品質、過程品質以及交付品質具有巨大的提升作用

 

相關文章推薦

如何理解持續集成、持續交付和持續部署

 

最後,文末福利,預約有驚喜!