构建测试的体系化思维（高级篇）
讀完需要
26
分鐘速讀僅需 9 分鐘
本文首發于個人網站「BY林子」，轉載請參考網站版權聲明。
👀
? ?
00 引言
測試人員缺乏體系化思維？
新建產品團隊或者新啟項目，如何系統化地測試？
組織級如何構建統一的測試體系？
? ?
1. 三個層次聊測試體系
大家都接觸過不計其數的測試、質量方面的文章或者培訓課程，內容不乏測試實踐、技術相關，但是卻很難構建自己的測試體系。基于很多朋友類似的困惑，結合本人多年的團隊實踐和咨詢經驗，從基礎篇、進階篇和高級篇三個不同的層次來跟大家探討測試體系化思維的構建。
《構建測試的體系化思維（基礎篇）》
《構建測試的體系化思維（進階篇）》
《構建測試的體系化思維（高級篇）》
? ?
2. 基礎篇和進階篇內容回顧
2022 年 1 月發布了《構建測試的體系化思維（基礎篇）》（后文簡稱《基礎篇》），從測試的五個基本職責出發，圍繞這五個基本職責介紹了相應的實踐活動和方法集。
理解和澄清業務需求
制定策略并設計測試
實現和執行測試
缺陷管理與分析
質量反饋與風險識別
3 月發布了《構建測試的體系化思維（進階篇） 》（后文簡稱《進階篇》），跳出測試，從軟件質量的角度來看體系化思維的構建。
從測試到質量：跳出測試，從質量維度來看測試的體系化建設。
質量保障與質量內建：質量是產品與生俱來的，質量內建才是保障質量的根本。
質量內建深入實踐：質量內建如何落地是大家最為關注的問題，深入質量內建實踐介紹，供大家落地實踐參考。
? ?
3. 高級篇內容概要
本文為高級篇，將從組織級別來看測試體系化思維的構建。
從團隊到整個組織：跳出產品/項目團隊，從整個組織范圍來看測試的體系化建設。
組織級測試體系圖譜：基于“一個中心，四個方向”圖譜，全面探討組織級測試體系建設。
組織級質量賦能：根據測試體系圖譜，從組織級層面對整個組織進行質量賦能。
👀
? ?
01 從團隊到組織
跳出產品/項目團隊，從整個組織范圍來看測試的體系化建設。
? ?
1. 為什么要從團隊到整個組織？
在《基礎篇》中聊到的測試基本職責和《進階篇》中聊到的質量內建，主要還是在團隊/項目范圍之內。但是，要真正做好測試體系建設或者說系統性地思考和開展質量保障工作，團隊的能力還是很有限，比如，下面這些場景有沒有覺得似曾相識？
我所在的組織有很多績效考核指標，工作靠績效驅動，感覺有些工作并不能帶來價值
我在一個獨立的測試部門，跟開發團隊的績效是不一致/矛盾的
業務部門離我很遠，所有開發和測試工作只能根據需求文檔開展
組織的各種評審流程很嚴格，對文檔要求很高，很多時間花在了寫文檔、走評審流程上
所開發的軟件產品對上下游都有依賴，測試數據的準備和測試環境的就緒需要很多等待
我不清楚其他團隊使用的工具、測試技術等具體細節
……
上面這些場景中的問題，都是很難在某個團隊內部解決的。因此，從組織范圍來看測試體系的建設，才是我們構建測試體系化思維的終極目標。
? ?
2. 組織級測試體系需要關注什么？
質量保障相關的人、流程、技術等放到組織層面，就是組織級測試體系需要關注的。通常有如下兩個方面的內容：
跟質量和測試密切相關的，包括質量目標、流程規范、測試策略、實踐標準等；
看似跟質量和測試沒有直接的關系，但是對質量保障工作的開展有著非常關鍵的影響，如組織結構、企業文化、各部門之間的合作方式等。
👀
? ?
02 組織級測試體系圖譜
組織級測試體系必然比團隊級要復雜得多，為了更好地理解和討論，將組織級測試體系需要關注的方方面面組織成如下圖所示圖譜：
該圖譜由“一個中心，四個方向”構成，要構建完備的組織級測試體系，建議圍繞“一個中心”、向四個方向發力：
一個中心：核心價值觀
四個方向：高效率協同、標準化指導、規范化實施、自動化支撐
? ?
1. 核心價值觀
核心價值觀是一個組織的文化理念，深刻地影響著組織內每個成員的行為，測試體系的構建需要以核心價值觀為指導。
1.1 價值驅動 vs. 指標驅動
絕大部分組織都會采用度量指標來對每個人的工作進行考核，因為這是一種比較簡單的衡量所做工作好與壞的方法，但這種方法也是相當粗暴的，因為“不是所有能測量的東西都重要，也不是所有重要的東西都可測量”。
過于看著指標，就會形成指標驅動，工作是為了滿足某種指標。測量什么，就一定能得到什么。一旦制定某個度量指標，員工一定會在工作中想盡辦法去滿足指標，而真正重要的工作內容是否完成就很難說了。這種指標驅動的工作方式，一定會忽略工作背后真正的價值。這是非常可怕的！在《指標陷阱(https://book.douban.com/subject/35115655/)》一書開篇就舉了兩個非常經典的例子：警察破案率、婦產科醫生的手術成功率。
我們來看一個軟件開發中以指標驅動的例子。在《速度（Velocity）不背這個鍋》一文中提到的“速度驅動一切”的誤區，就是軟件開發中錯誤地以指標（開發速度）來驅動開發的實例。如下所示：
- 周報里的速度保持穩定，每周每對 pair 在 2 個點上下；
- 性能調優，客戶覺得目前看不到價值不給點，所以團隊就不做了；
- 技術改進，同樣的，客戶看不到價值不給點，就不做了；或者團隊實在無法忍受想要改進，那就從別的功能用戶故事里多估算一些點來留時間給做技術改進；
- 目前組內開發速度不夠，用戶故事都做不完了，生產環境的 support 能給別的組就給別的組做吧，那個太耽誤開發進度了！
相信各位朋友要舉出軟件開發中指標驅動的例子，一定是信手拈來，此處不再多述。
那么，是不是就沒必要度量了呢？也不是，適當的度量還是很有必要的。度量可以作為團隊改進的牽引，幫助團隊提高。
但是，工作不可以以任何度量指標為目標，不能由度量指標驅動，而是要以價值驅動。軟件開發是需要交付能夠帶來業務價值的、高質量的軟件，圍繞這個價值目標所做的工作才是有意義的。因此，軟件的質量保障、軟件測試也要以業務價值驅動。關于這部分內容，請參考文章《業務價值驅動的測試》。
從組織層面來講，需要構建價值驅動的文化，引導員工更多地關注價值，弱化度量指標帶來的不良影響，以防掉入指標陷阱。
1.2 鼓勵創新 vs. 追責文化
績效考核的一個直接后果就是追責，追責文化是跟績效指標緊密關聯的。績效指標沒有達到，甚至是出現意外，是采取追責還是改進的措施，將直接影響到員工的行為、態度和解決問題的方法。比如：
線上出現嚴重故障，最終會調查追責到人，并施以懲罰；還是會分析故障原因，找出后續如何避免的改進舉措呢？
如果是前者，一旦出現問題，所有相關人員會提心吊膽，很難客觀地分析和解決問題，反而會有某些隱瞞因素存在，導致下次可能還會重復出現類似問題。關于后者，之前在文章《缺陷分析如何幫助質量內建》中有關于故障/缺陷分析的詳細實踐，這里想要強調一點的是缺陷分析，分析到問題出現的客觀原因即可，無需追責到人。
一個非常典型的不追責例子是敏捷回顧會議所遵循的最高指導原則(https://retrospectivewiki.org/index.php?title=The_Prime_Directive)：
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
（“無論我們揭示了什么，我們必須理解并真正相信：考慮到當時的已知情況、每個人的技能和能力、可用資源和情境，每個人都做到了最好。”）
-- Norm Kerth, Project Retrospectives: A Handbook for Team Review
不追責的另一面是鼓勵創新。成功來自于不停地試錯，要想把事情做好，需要不斷地嘗試，經歷多次的不成功，并且在一次次失敗中總結經驗教訓，從而獲得進步。例如，高科技公司谷歌和亞馬遜，都是非常鼓勵創新的。
組織要宣揚這種創新文化，給予員工適當的創新空間，鼓勵大家積極地嘗試新點子，以不斷改進軟件開發流程，提高軟件交付質量。
1.3 全員負責 vs. 獨立割裂
對于軟件開發團隊來說，“團隊對質量負責”幾乎已經是家喻戶曉了。但是，從組織級來看，團隊該怎么定義？道理都明白，具體到實施層面，又是怎么做的呢？
據我所知的現實情況，部門與部門之間、團隊不同角色之間還是比較割裂的，還有許多人認為質量主要是測試（部門/團隊/人員）的事情，而業務負責業務需求、開發負責編碼、運維負責線上就行了。
之前寫過幾篇團隊對質量負責的文章，歡迎移步閱讀：
《團隊為質量負責，“我”可以不負責？》
《敏捷測試的指導性原則——團隊對質量負責》
《說好的團隊為質量負責呢？》
從組織角度來看，需要明確質量目標，并讓全體成員知曉，以質量目標驅動各個職能部門間的合作，增強全員對質量負責的意識。
? ?
2. 高效率協同
高效率協同強調的是組織結構形式，以及組織內各部分的協同方式，這是組織級測試體系構建非常關鍵的一部分。
2.1 組織結構
設計系統的結構受制于產生這些設計的組織的溝通結構。
—— M. Conway（馬爾文·康威）
馬爾文·康威 1967 年提出的康威定律（康威法則, Conway's Law），即系統設計本質上反映了企業的組織結構。
軟件開發是一項復雜的社會活動，需要業務、開發、測試和運維以及團隊與團隊之間等充分地溝通協作才能實現，根據康威定律，需要對組織結構進行相應的調整以適應軟件研發的需要。
而傳統的企業通常都有著非常厚重的部門墻，業務和科技之間，開發和測試、以及運維之間，都分別屬于不同的部門，并且這種部門墻非常難以打破。這無疑是非常大的矛盾之處。
例如，傳統企業通常都有獨立而龐大的測試部門/測試團隊，在獨立的測試階段來承接測試工作；在新形勢下要求持續測試，不再有非常獨立的測試階段，測試部門該如何調整以更好地與研發進行高效合作是備受關注的問題，也是組織建立完善的測試體系需要解決的問題。
該怎么解決？比較常見的有兩種方式：
保持原有獨立測試部門，測試人員歸屬于測試部門管理，但是派駐到研發團隊，在研發團隊內實施測試工作；
不再設有測試部門，測試人員全部打散，并入研發中心，跟研發團隊進行深度融合。
上面哪種方式比較好？很難說。
從形式上看，完成融合的第二種方式看起來是較好的，能夠實現開發和測試更深入的融合，但是這對團隊也是有很高要求的，需要在測試左移、團隊對質量負責等方面都做的足夠好，才能對于質量有讓人放心的保障。因此，對于質量要求非常高的行業，比如金融領域，比較容易接受的可能是第一種方式，一是因為傳統的部門墻打破實在太難，還有很重要的一方面是還有獨立的測試部門對質量“把關”，似乎能讓大家更放心。
至于自己的組織適合哪一種形式，還是需要組織自己去摸索。
2.2 團隊拓撲
組織應該被視為一個復雜的具有適應性的有機體，而非一個機械的線性系統。
—— Naomi Stanford，摘自《組織設計指南》（Guide to Organization Design)
《高效能團隊模式(https://book.douban.com/subject/35528423/)》一書中指出組織結構的陷阱：傳統的組織結構圖是相對靜態的，并不能幫助我們理解組織中真實的溝通模式，在實際的軟件開發過程中可能有很多不依賴于組織結構圖中所體現的溝通存在，這種適應軟件開發的溝通結構是更為關鍵而有價值的。因此，提出團隊拓撲的概念。
[《高效能團隊模式》作者總結的團隊拓撲Team Topologies](https://hennyportman.wordpress.com/2020/05/25/review-team-topologies/)
團隊拓撲方法圍繞企業軟件交付的有效團隊結構，帶來了一種全新的思維方式。提供了四類基本的團隊類型：流動式團隊、平臺團隊、賦能團隊和復雜子系統團隊，以及三種團隊核心交互模式：協作模式、服務模式和促進模式。強調了在靜態的組織結構（團隊結構）之外，更多地關注實際的溝通路徑，針對技術組織補充了傳統組織設計中所缺少的動態和感知方面的能力。
回顧前面提到的測試部門如何組織的問題，基于團隊拓撲思想，我們可能會想到不一樣的解決方案，加強測試跟各個部門/角色的交互才是關鍵所在，需要根據產品開發需求構建靈活適應的團隊拓撲結構，具體的組織形式或許不是最重要的。
2.3 溝通協作
團隊拓撲強調了組織溝通結構的重要性，在滿足溝通模式的團隊構建好之后，是不是就一定能實現相應的溝通需求呢？也不見得。
例如，下面的一些情況可能大家都或多或少經歷或者聽說過：
有些業務目標、質量目標可能只是“高層”領導人員清楚，沒有對全組織、全團隊透明；
有的企業，業務和研發團隊坐在一起，但是溝通方式跟原來沒有區別，還是通過需求文檔來進行溝通；
有的團隊，測試和開發同屬于一個團隊，但是測試不會參與開發的技術討論，開發有技術方面更新不會告知測試人員，開發不會參與測試策略和測試計劃的制定等；
同一個產品或者項目的不同小團隊各自為伍，沒有知識和信息共享，導致重復造輪子的事情時有發生……
類似的情況可能還有很多。這些都是形式上貌似沒有問題，但實質上缺乏有效的溝通協作。
關于溝通，首先要重視溝通的內容，盡量讓信息在整個組織或者整個團隊內透明，尤其是關于愿景、目標和風險類的信息，可以增強成員使命感和主觀能動性。我在《敏捷測試的指導性原則》里介紹了高效合作的團隊特點，在《警惕團隊“蘑菇種植”》中也通過一些事例分享了信息共享的重要性。
另一方面，對于溝通的形式也要注意，不同的溝通形式所能起到的效果也是截然不同的。通常，面對面的溝通是最為有效的方式。如下圖所示：
協作建立在充分溝通的前提上，一旦溝通到位了，協作起來就會順暢很多。
? ?
3. 標準化指導
之前寫過一篇文章《敏捷團隊的質量保障賦能》，文中通過對 Google、Amazon 和 Facebook 等大公司的軟件開發交付流程的分析，總結了團隊質量保障賦能需要做到全流程的標準化。
通過標準化工作方式的指導，讓團隊能更好地做到每個環節的質量保障，更好地實現團隊為質量負責。標準化一定要注意不要只流落于書面形式，參考《敏捷團隊的質量保障賦能》中的“事實標準與書面標準”。
3.1 研發流程的標準化
測試和開發是密不可分的，測試策略受到不同開發流程的影響。
不管是傳統瀑布式的開發流程，還是迭代式的敏捷開發流程，或者兩者相結合的開發方式，都需要將相應的流程策略標準化下來，每個環節的活動有哪些，不同人員的職責分別是什么，都需要在組織級有清晰的定義。
在標準化的研發流程指導下，團隊如果發現某個環節成為瓶頸，一定要詳細分析原因，如果是流程已經不適應新的團隊現狀，也是需要調整和改進的。
3.2 測試策略的標準化
針對不同的開發流程，需要有對應的組織級標準化測試策略。組織級測試策略是個統一的指導方向，不同的產品線和不同的項目團隊也需要有自主調整的空間，以更好地定制化適配的策略。
除了需要給團隊自主調整策略的空間，還有一點要強調的是策略不是一成不變的，需要根據不同時期的質量風險和團隊狀態進行適配和調整，應該是演進式的。
關于測試策略，強烈推薦參考《一頁紙測試策略》，并根據所在組織自己的特點來定制化。
3.3 質量目標和度量策略標準化
清晰的質量目標能夠更好地驅動組織級測試體系的構建。組織級的質量目標，一方面是純系統使用方面的質量要求，更為關鍵的另一方面，應該是跟業務目標緊密關聯的，是需要以業務價值來驅動的。關于業務價值與測試，可以參考我的下列文章：
《業務價值驅動的測試》
《敏捷測試如何優化業務價值》
談到質量目標，勢必需要相應的度量指標和度量策略，組織級需要對質量目標定義相應的指標，并且通過組織統一的度量策略來衡量。度量，特別需要關注的是不可以只看單一指標，而應該是綜合多個指標衡量；也不適合將指標作為產品線/團隊橫向比較的標準，指標應該是指導產品線/團隊自身持續改進的尺子，非常同意 Thoughtworks 同事伍斌道長在他的文章《度量就是為了識別價值流最大瓶頸》中寫的：
“在敏捷 IT 研發交付中，度量的作用，就好比是在識別價值流中最大的堵塞點，以便在“價值準、流速快、質量好”這 3 個維度中，識別端到端價值流最大瓶頸（以及方向錯誤），并將其作為下一步改進點進行改進，以最大化改進成效。”
作者：吾真本
鏈接：https://www.jianshu.com/p/91eaf583ca3b
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
關于質量度量，Thoughtworks 同事于曉南從定性和定量兩個角度進行過非常詳細的分享，并且撰寫過一系列相關文章，歡迎參考她的《質量度量文集》。
? ?
4. 規范化實施
在標準化策略的指導下，如何保證每個實踐活動都能做到位是個比較難的問題：有的實踐可能一開始就實施錯了；或者剛開始是正確的，但是過了一段時間，實踐就變味兒了……
規范化的實施方案是對標準化策略落地實施的保障。組織級需要從以下幾個方面考慮各個實踐活動的有效落地實施：定義實踐活動規范、沉淀新的優秀實踐、定制化成熟度模型、定期治理與持續改進。
4.1 定義實踐活動規范
對每個實踐活動進行清晰的定義，包括實踐的目標、適用條件、參與角色、輸入輸出等，最好用實例化的方式詳細介紹整個實踐活動的內容。可以采用畫布的方式對前面幾項列舉介紹，更加清晰直觀。
定義好的實踐規范是團隊實施落地的參考，在團隊實踐過程中，也鼓勵團隊根據實踐經驗去完善每個實踐活動，實現持續的優化。
4.2 沉淀新的優秀實踐
團隊在實踐過程中，也會摸索出一些新的實踐活動，建議將新的實踐活動分享給更多的團隊，推薦大家試用，一旦得到多個團隊的認可，可以將這個實踐活動也規范化，沉淀下來，存入組織級實踐庫中。
同時，對于一些不再適用的實踐活動，也要進行淘汰和剔除。
4.3 定制化成熟度模型
基于實踐標準的成熟度模型，可以評估團隊每個階段的實踐實施狀況，并制定相應的改進舉措，以幫助團隊的不斷成長。組織級需要制定指導性的成熟度模型，供每個團隊去定制化，以牽引團隊的改進。這塊內容歡迎參考我的文章《測試成熟度評估》。
特別要強調一點：成熟度模型的目的不是用來評估，主要是為了指導改進；成熟度如果要跟團隊績效關聯，務必謹慎，不然就會陷入指標陷阱。
4.4 定期治理與持續改進
光有成熟度模型沒用，要能指導改進，定期治理很重要。組織級層面需要制定定義質量治理策略，落到每個團隊來講，就是可以根據成熟度模型，定期對過去一段時間實踐落地情況進行回顧，對現狀進行評估，根據回顧和評估結果，并結合當下的質量目標，制定新的改進舉措。
比如，可以鼓勵團隊根據迭代周期、發布周期等進行定期回顧和治理；也可以根據改進舉措的粒度大小，對不同舉措進行不同周期的治理和改進。
總之，組織級要有定期治理和持續改進的意識，結合成熟度模型，鼓勵團隊實現持續改進。
? ?
5. 自動化支撐
強有力的基礎設施能夠對質量實踐活動落地實施提供自動化支撐，同步提升質量與效能。
從測試體系構建的角度來講，組織級需要全盤考慮幾個領域的自動化支撐：
流程管理：全生命周期的軟件交付流程，通常需要有流水線的支撐
測試框架：各種自動化測試框架，以及與持續集成流水線的關聯
數據分析：可視化各種數據及其分析結果，包括日志信息和度量指標數據等
監控預警：實時監控團隊和產品狀態，對質量風險和嚴重缺陷進行智能預測和告警
只要聊到效能，大家腦海里就會冒出各種效能支持平臺和工具，這部分內容是非常熟悉的，無需多述……不過，鑒于大家對工具平臺的熱衷程度，非常有必要提醒幾點：
1. 強調工具平臺的使用，但人員缺乏相應的賦能，不清楚工具平臺背后的原理，從而無法高效使用。
平臺廠商和采購平臺的企業都有人跟我聊過這個現象，說明不是個例。工具平臺再好，也只有用對了才能事半功倍，不然就是個負擔。
2. 標準規范停留在書面上，根本沒有落地實施。
這就是前面提到的《敏捷團隊的質量保障賦能》中的“事實標準與書面標準”，而工具平臺是有助于將書面標準變成事實標準的。
3. 不同的團隊采用不同的工具框架，組織沒有統一工具平臺的使用。
這將不利于不同團隊間的協作和集成，不利于組織級數據的收集，會增加多余的成本。不要重復造輪子，能夠共享的工具平臺一定要在組織內共享，一致的工具平臺對數據的收集和可視化都會帶來好處。同時，也要考慮團隊優先適配的問題，比如某個團隊的自動化測試最佳方案是用工具 A，非強調要組織級統一，強制使用工具 B，那也是不合適的。萬事皆需平衡。
👀
? ?
03 組織級質量賦能
根據前面介紹的測試體系圖譜，總體來說，組織級質量賦能要著重關注以下幾個方面：
? ?1. 樹立適應新時代軟件質量要求的價值觀，營造全員重視質量和價值交付的組織文化
隨著科技的持續發展，軟件生態日益復雜，新時代軟件質量有著更高的要求，軟件質量保障也面臨更大的挑戰，傳統的質量保障、軟件測試的思路不能完全適合。而是需要改變傳統的認知觀念，實現多角色深度融合、協同作戰、全員為質量負責，重視質量和價值交付。
? ?2. 朝著全流程標準化的方向前行，降低質量成本
全流程標準化是大勢所趨，但一步到位也是比較難，分步走的策略才是可行的：
首先，定義組織級統一的流程策略，形成書面標準；
同時，制定實踐活動規范，以指導書面標準的落地實施；
通過部分團隊實踐驗證，逐步推廣并標準化固定下來，形成組織級標準；
利用工具支撐設置質量門禁等方式確保書面標準能夠真正落地，并持續改進和優化策略標準和實踐規范。
? ?3. 強化質量基礎設施建設，擴大自動化規模，提升研發效能
大規模自動化是實現全流程標準化的有利助手，組織級測試體系需要從測試自動化和流程自動化兩個方向加強基礎設施建設，兩者缺一不可。
? ?4. 人員能力是關鍵，加強能力建設不容忽視
一方面，制定組織級人才培養機制，針對不同角色建立相應的能力模型和提升路徑，形成人才梯度，有計劃地實現人員能力建設；同時，鼓勵社區建設，營造學習型文化氛圍，以促進人員自主學習和提升。
關于測試人員能力提升，可以參考下列文章部分內容：
《數字化轉型背景下的測試轉型》
《軟件測試人員該何去何從》
👀
? ?
04 最后
繼《基礎篇》針對測試人員的基本職責和《進階篇》針對的全生命周期的質量內建之后，本《高級篇》通過介紹“一個中心，四個方向”的組織級測試體系圖譜，以幫助實現組織級質量賦能。
至此，構建測試的體系化思維系列的基礎、進階和高級三個層次的內容均已完成，希望能夠提供一個幫助大家思考的測試體系框架。
總結
以上是生活随笔為你收集整理的构建测试的体系化思维（高级篇）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php mysql grant_mysq
- 下一篇： 【Jmeter篇】Jmeter分布式调度