前言
從事軟件測試相關工作七年，做過功能測試、自動化測試、測試開發、性能測試、專項測試，也干過一段時間技術管理。
近幾年隨着行業成熟度的發展，對軟件測試也有了更高的要求，很多測試團隊開始轉變為質量保障團隊。
如何從質量保障的維度去更好的為業務提供支持，是我一直在思考的事情。
整理了自己的很多筆記，結合我在工作中遇到的種種場景，我梳理出了下面這張質量保障體系思維導圖，供大家參考。
思維導圖
三大體系
組織
願景
所謂的願景，就是長期規划，我們要到哪里去的問題。一個組織或者團隊，是一定要有願景的。在軟件質量保障領域，所謂的願景概括來說就四個字：保質提效。
保質，就是在日常交付中保障軟件質量，並且在長期發展過程中，不斷提高軟件的質量。如何評估質量是否是穩定且不斷提升的，就需要引入評估體系，用事實、結果、背后的分析邏輯和數據來證明。
提效，很好理解，提高效率。怎么提高效率呢？引入ROI體系，從交付時間、耗用資源、團隊成長方面着手。
目標
有了願景，還要將其拆分為不同的目標。行業在變，組織架構在變，因此目標也要跟隨整體的變化而調整。
不同的企業在不同階段有不同的側重點和訴求。你不能要求一個初創企業要啥啥都有，也不能要求BAT啥都湊合。這是一個平衡和抉擇的過程，可以參考CMMI模型來思考這一點。
規則
這里的規則不是強制要求大家一定要做什么，而是為了避免某些方式對團隊和企業帶來不好的影響。常見的規則比如：周報、信息同步機制、反饋機制
文化
談到文化這一塊，一直是很務虛的東西，很多同學對之嗤之以鼻，2020年之前我也是這么想的。
20年讀了一本書：《重新定義公司：Google是如何運營的》。里面對企業文化這一部分做了很經典的解釋：企業文化就是指導員工面臨艱難選擇時，做正確的選擇。
管理
團隊管理方面，我將其分為了下面四個體系，每個體系都包含不同的內容。
相關內容，可參考我之前的文章：從技術專家到技術管理，我對管理的思考
業務體系
如果團隊規模較小，業務也不復雜，可以暫時不用拆分。但是當人數超過10人&業務開始划分不同團隊時候，就要考慮做業務拆分了。
這里的業務拆分指的是根據組織架構將測試同學分為不同的組，每個組有一個小組長或team leader，提高管理效率，做好信息同步和反饋機制。
避免自己成為團隊的瓶頸，從繁雜的管理中抽身出來，去思考並解決更高維度的問題。
資源體系
在團隊管理中，無論是人力、設備還是時間，都可以納入資源管理體系中。我將其分為了如下三個部分：
1、人力模型
- 新人目標：新人入職如何落地？如何快速適應業務迭代節奏？如何設定合理的目標來達成預期結果？
- 轉正述職：招聘、新人培養都需要成本投入，設定合理明確的轉正評估機制，結合上述的新人目標，可以幫助新人更好的落地。
2、能力模型
- 成長模型：工作一方面為了金錢物質回報，另一方面也是希望能夠借助平台獲得自我成長。設定成長目標和模型，可以幫助員工在不同的階段知道自己該向什么方向努力，達成不同階段的不同目標，這是沒一個管理者都需要考慮的事情。
- 勝任力模型：一個團隊的組織結構，從初級的倒T型，經過金字塔模型，最終演變成紡錐型。在不同階段，隨着組織結構的演變，處在不同階段和層級的員工，需要設定不同的級別和勝任評估體系，助力團隊跟隨公司不斷發展，適應組織結構的變化。一般來說，可以從工作經驗、技術、業務熟悉度、項目推動能力、溝通協同方面來設定評估指標。
3、資產管理
- 雲端資產：現在大多數互聯網公司，都采用了雲服務。對於質量保障團隊來說，測試環境及內部自建技術平台涉及的雲端資產，都需要通過一定的手段管理起來。當然一般這種事在運維團隊，有CMDB體系來進行管理，可進行參考。
- 硬件資產：這里的硬件資產包括移動端測試機&pad等設備，當然可能也包括用來做兼容測試而采購的相關服務等設施。還有一點，員工辦公所使用的包含電腦顯示器等設備，一般會有IT部門來專門登記管理。如果沒有，建議做好統計，便於員工入離職交接等。
知識體系
這里的知識體系，主要指的是團隊內部的能力建設和沉淀，主要包含如下幾個方面：
1、技術博客
無論是工作職場中還是和同行交流中，我一向是比較鼓勵大家寫技術博客的。
這樣無論是對個人知識的梳理總結，還是團隊的技術能力沉淀都是有很大幫助的。長期以往堅持下來，還能形成品牌向外宣傳，這也是吸引優秀候選人的一個方式。
2、業務串講：前面提到隨着企業的發展，業務規模越來越大也越來越復雜，業務串講就顯得很有必要。優點如下：
- 幫助不同team的同學了解不同的業務，便於日常工作理解；
- 遇到不同團隊協同工作時，更明確交接的業務邊界，提供溝通效率；
- 沉淀成業務知識庫，可以讓其他團隊的同學&新入職的同學快速了解，離入職交接也更方便；
3、內部分享：這里的內部分享，指的是技術部門內部，上述的技術博客和業務串講&知識庫，都可以作為分享的素材來宣講。
一方面可以讓更多的同學了解到不同的知識，另一方面加深團隊的影響力，這樣有助於日常工作的開展。也能在一定程度上培養團隊同學的溝通和表達能力。
4、外部培訓：這個主要指下面幾方面：
- 聯合開源社區，合作舉辦技術沙龍、座談會等類似的活動；
- 重量級的技術大會上做主題分享，主要目的是價值宣導和品牌影響力建設；
評估體系
如何理解這里的評估體系？圍繞上文提到的保質提效相關的點，來分類進行評估。
1、問題管理
- 測試過程中遇到的BUG，分門別類，階段性的總結梳理，輸出質量保障參考手冊/SOP；
2、版本管理
- 版本管理主要涵蓋每個版本的服務發版次數、冒煙通過率、bug的reopen率、上線質量等因素。每個版本結束，除了向上做匯報，內部的復盤總結優化，也是很重要的。
3、項目管理
- 這里的項目管理，可以理解為PMO這個崗位做的一些事情，包括進度、風險、資源、deadline等因素。實際上無論是版本發布、和版本迭代同步進行的跨版本需求以及內部的一些獨立項目，都可以采用這種方式來管理，總體上還是為了提高資源利用率以及風險前置。
4、效率管理
- 效率管理，我們之前的做法，一方面是通過調查問卷的方式，在部門內部開展調查，獲取日常工作中影響工作效率的點，歸納匯總進行專項優化。另一方面，隨着團隊規模的不斷擴大，整體的效率問題也會變成團隊成長的一大問題，需要時刻重視。
專項
自動化體系
自動化體系的建設，目前來說在絕大多數稍有規模的互聯網公司，都有不同的應用。
有UI自動化、APP自動化、接口自動化、單測自動化、埋點自動化以及自動化打包發布校驗等方式。
最初的目標都是提高效率，降低手工的成本，讓工作的個體突出發揮自己的思考能力，而不是手工的體力勞動。
在自動化體系建設中，主要需要考慮如下幾點：
- 場景&用例&執行：這里需要注意的是場景的覆蓋、用例的篩選以及執行效率；
- 框架&數據&CICD：人多了，需要注意避免團隊內部造輪子，擼很多自動化框架。我個人對這點的理解是有成熟開源框架的，別自己造輪子。內部已有的，評估是否需要優化，而不是推到重構。自動化體系中，CICD是至關重要的一環，別忘記自動化的初衷。
- 提效&反饋&參與：自動化最終還是要解決的是效率問題，如上文提到的效率管理，需要持續不斷的獲得反饋，然后改進優化。說到參與，很多公司是自動化和功能測試工程師做了區分，實際上如果為了團隊的整體成長，需要全員參與進來，有參與感，員工才能有收獲和滿足感。否則大部分人只靠工作本身的內容，是很難做到主動提升自己的。
防資損體系
什么叫資損？造成公司&客戶資產損失的都算。比如公司發優惠券，多發且被用戶使用了，造成公司成本支出。
比如用戶的優惠券滿足場景但無法在支付中使用，用戶有了資損，實際上還是公司買單。還有部分輿情方面的東西，比如某個外部消息導致公司上了熱搜，外部對公司的評價變差，對企業品牌造成不良影響。
我們之前的做法是線上監控及時告警，專人專群處理。還有線上涉及資損的場景進行針對性校驗，盡可能降低資損的成本以及造成的影響。
質量大盤體系
這里的質量大盤，大家理解為一個可視化的監控即可。即把上面我們提到的各項規則和措施，通過數據量化的方式管控起來，便於做決策。
性能測試體系
性能測試體系，由於之前的文章已經詳細介紹過，這里不過多贅述，大家可以參考之前的文章。
文章鏈接：性能測試體系建設演進之路
穩定性治理體系
穩定性是一個很大的范疇，在質量保障體系中，穩定性的建設，主要集中在如下幾點：
- 測試過程監控（如自動化通過率&冒煙通過率&性能容量變化趨勢等）
- 測試環境穩定性治理（特別是有多套環境多個項目版本交叉使用以及頻繁發布）
- 線上服務可用性監控（質量保障不僅只關注測試環境，線上的穩定性也至關重要）
寫在最后
總感覺自己寫了很多，又好像有很多內容無法一一表達。關於本篇文章中提到的部分內容，如穩定性治理，會在后續的文章中進行詳細介紹。
本文僅供參考，請知悉。