讀完需要

26

速讀僅需 9 分鐘

本文首發(fā)于個人網(wǎng)站「BY林子」，轉(zhuǎn)載請參考網(wǎng)站版權(quán)聲明。

👀

? ?

00 引言

測試人員缺乏體系化思維？
新建產(chǎn)品團(tuán)隊(duì)或者新啟項(xiàng)目，如何系統(tǒng)化地測試？
組織級如何構(gòu)建統(tǒng)一的測試體系？

? ?

1. 三個層次聊測試體系

大家都接觸過不計(jì)其數(shù)的測試、質(zhì)量方面的文章或者培訓(xùn)課程，內(nèi)容不乏測試實(shí)踐、技術(shù)相關(guān)，但是卻很難構(gòu)建自己的測試體系。基于很多朋友類似的困惑，結(jié)合本人多年的團(tuán)隊(duì)實(shí)踐和咨詢經(jīng)驗(yàn)，從基礎(chǔ)篇、進(jìn)階篇和高級篇三個不同的層次來跟大家探討測試體系化思維的構(gòu)建。

• 《構(gòu)建測試的體系化思維（基礎(chǔ)篇）》

• 《構(gòu)建測試的體系化思維（進(jìn)階篇）》

• 《構(gòu)建測試的體系化思維（高級篇）》

? ?

2. 基礎(chǔ)篇和進(jìn)階篇內(nèi)容回顧

2022 年 1 月發(fā)布了《構(gòu)建測試的體系化思維（基礎(chǔ)篇）》（后文簡稱《基礎(chǔ)篇》），從測試的五個基本職責(zé)出發(fā)，圍繞這五個基本職責(zé)介紹了相應(yīng)的實(shí)踐活動和方法集。

• 理解和澄清業(yè)務(wù)需求

• 制定策略并設(shè)計(jì)測試

• 實(shí)現(xiàn)和執(zhí)行測試

• 缺陷管理與分析

• 質(zhì)量反饋與風(fēng)險識別

3 月發(fā)布了《構(gòu)建測試的體系化思維（進(jìn)階篇） 》（后文簡稱《進(jìn)階篇》），跳出測試，從軟件質(zhì)量的角度來看體系化思維的構(gòu)建。

• 從測試到質(zhì)量：跳出測試，從質(zhì)量維度來看測試的體系化建設(shè)。

• 質(zhì)量保障與質(zhì)量內(nèi)建：質(zhì)量是產(chǎn)品與生俱來的，質(zhì)量內(nèi)建才是保障質(zhì)量的根本。

• 質(zhì)量內(nèi)建深入實(shí)踐：質(zhì)量內(nèi)建如何落地是大家最為關(guān)注的問題，深入質(zhì)量內(nèi)建實(shí)踐介紹，供大家落地實(shí)踐參考。

? ?

3. 高級篇內(nèi)容概要

本文為高級篇，將從組織級別來看測試體系化思維的構(gòu)建。

• 從團(tuán)隊(duì)到整個組織：跳出產(chǎn)品/項(xiàng)目團(tuán)隊(duì)，從整個組織范圍來看測試的體系化建設(shè)。

• 組織級測試體系圖譜：基于“一個中心，四個方向”圖譜，全面探討組織級測試體系建設(shè)。

• 組織級質(zhì)量賦能：根據(jù)測試體系圖譜，從組織級層面對整個組織進(jìn)行質(zhì)量賦能。

👀

? ?

01 從團(tuán)隊(duì)到組織

跳出產(chǎn)品/項(xiàng)目團(tuán)隊(duì)，從整個組織范圍來看測試的體系化建設(shè)。

? ?

1. 為什么要從團(tuán)隊(duì)到整個組織？

在《基礎(chǔ)篇》中聊到的測試基本職責(zé)和《進(jìn)階篇》中聊到的質(zhì)量內(nèi)建，主要還是在團(tuán)隊(duì)/項(xiàng)目范圍之內(nèi)。但是，要真正做好測試體系建設(shè)或者說系統(tǒng)性地思考和開展質(zhì)量保障工作，團(tuán)隊(duì)的能力還是很有限，比如，下面這些場景有沒有覺得似曾相識？

• 我所在的組織有很多績效考核指標(biāo)，工作靠績效驅(qū)動，感覺有些工作并不能帶來價值

• 我在一個獨(dú)立的測試部門，跟開發(fā)團(tuán)隊(duì)的績效是不一致/矛盾的

• 業(yè)務(wù)部門離我很遠(yuǎn)，所有開發(fā)和測試工作只能根據(jù)需求文檔開展

• 組織的各種評審流程很嚴(yán)格，對文檔要求很高，很多時間花在了寫文檔、走評審流程上

• 所開發(fā)的軟件產(chǎn)品對上下游都有依賴，測試數(shù)據(jù)的準(zhǔn)備和測試環(huán)境的就緒需要很多等待

• 我不清楚其他團(tuán)隊(duì)使用的工具、測試技術(shù)等具體細(xì)節(jié)

• ……

上面這些場景中的問題，都是很難在某個團(tuán)隊(duì)內(nèi)部解決的。因此，從組織范圍來看測試體系的建設(shè)，才是我們構(gòu)建測試體系化思維的終極目標(biāo)。

? ?

2. 組織級測試體系需要關(guān)注什么？

質(zhì)量保障相關(guān)的人、流程、技術(shù)等放到組織層面，就是組織級測試體系需要關(guān)注的。通常有如下兩個方面的內(nèi)容：

• 跟質(zhì)量和測試密切相關(guān)的，包括質(zhì)量目標(biāo)、流程規(guī)范、測試策略、實(shí)踐標(biāo)準(zhǔn)等；

• 看似跟質(zhì)量和測試沒有直接的關(guān)系，但是對質(zhì)量保障工作的開展有著非常關(guān)鍵的影響，如組織結(jié)構(gòu)、企業(yè)文化、各部門之間的合作方式等。

👀

? ?

02 組織級測試體系圖譜

組織級測試體系必然比團(tuán)隊(duì)級要復(fù)雜得多，為了更好地理解和討論，將組織級測試體系需要關(guān)注的方方面面組織成如下圖所示圖譜：

該圖譜由“一個中心，四個方向”構(gòu)成，要構(gòu)建完備的組織級測試體系，建議圍繞“一個中心”、向四個方向發(fā)力：

• 一個中心：核心價值觀

• 四個方向：高效率協(xié)同、標(biāo)準(zhǔn)化指導(dǎo)、規(guī)范化實(shí)施、自動化支撐

? ?

1. 核心價值觀

核心價值觀是一個組織的文化理念，深刻地影響著組織內(nèi)每個成員的行為，測試體系的構(gòu)建需要以核心價值觀為指導(dǎo)。

1.1 價值驅(qū)動 vs. 指標(biāo)驅(qū)動

絕大部分組織都會采用度量指標(biāo)來對每個人的工作進(jìn)行考核，因?yàn)檫@是一種比較簡單的衡量所做工作好與壞的方法，但這種方法也是相當(dāng)粗暴的，因?yàn)椤安皇撬心軠y量的東西都重要，也不是所有重要的東西都可測量”。

過于看著指標(biāo)，就會形成指標(biāo)驅(qū)動，工作是為了滿足某種指標(biāo)。測量什么，就一定能得到什么。一旦制定某個度量指標(biāo)，員工一定會在工作中想盡辦法去滿足指標(biāo)，而真正重要的工作內(nèi)容是否完成就很難說了。這種指標(biāo)驅(qū)動的工作方式，一定會忽略工作背后真正的價值。這是非常可怕的！在《指標(biāo)陷阱(https://book.douban.com/subject/35115655/)》一書開篇就舉了兩個非常經(jīng)典的例子：警察破案率、婦產(chǎn)科醫(yī)生的手術(shù)成功率。

我們來看一個軟件開發(fā)中以指標(biāo)驅(qū)動的例子。在《速度（Velocity）不背這個鍋》一文中提到的“速度驅(qū)動一切”的誤區(qū)，就是軟件開發(fā)中錯誤地以指標(biāo)（開發(fā)速度）來驅(qū)動開發(fā)的實(shí)例。如下所示：

- 周報里的速度保持穩(wěn)定，每周每對 pair 在 2 個點(diǎn)上下；
- 性能調(diào)優(yōu)，客戶覺得目前看不到價值不給點(diǎn)，所以團(tuán)隊(duì)就不做了；
- 技術(shù)改進(jìn)，同樣的，客戶看不到價值不給點(diǎn)，就不做了；或者團(tuán)隊(duì)實(shí)在無法忍受想要改進(jìn)，那就從別的功能用戶故事里多估算一些點(diǎn)來留時間給做技術(shù)改進(jìn)；
- 目前組內(nèi)開發(fā)速度不夠，用戶故事都做不完了，生產(chǎn)環(huán)境的 support 能給別的組就給別的組做吧，那個太耽誤開發(fā)進(jìn)度了！

相信各位朋友要舉出軟件開發(fā)中指標(biāo)驅(qū)動的例子，一定是信手拈來，此處不再多述。

那么，是不是就沒必要度量了呢？也不是，適當(dāng)?shù)亩攘窟€是很有必要的。度量可以作為團(tuán)隊(duì)改進(jìn)的牽引，幫助團(tuán)隊(duì)提高。

但是，工作不可以以任何度量指標(biāo)為目標(biāo)，不能由度量指標(biāo)驅(qū)動，而是要以價值驅(qū)動。軟件開發(fā)是需要交付能夠帶來業(yè)務(wù)價值的、高質(zhì)量的軟件，圍繞這個價值目標(biāo)所做的工作才是有意義的。因此，軟件的質(zhì)量保障、軟件測試也要以業(yè)務(wù)價值驅(qū)動。關(guān)于這部分內(nèi)容，請參考文章《業(yè)務(wù)價值驅(qū)動的測試》。

從組織層面來講，需要構(gòu)建價值驅(qū)動的文化，引導(dǎo)員工更多地關(guān)注價值，弱化度量指標(biāo)帶來的不良影響，以防掉入指標(biāo)陷阱。

1.2 鼓勵創(chuàng)新 vs. 追責(zé)文化

績效考核的一個直接后果就是追責(zé)，追責(zé)文化是跟績效指標(biāo)緊密關(guān)聯(lián)的。績效指標(biāo)沒有達(dá)到，甚至是出現(xiàn)意外，是采取追責(zé)還是改進(jìn)的措施，將直接影響到員工的行為、態(tài)度和解決問題的方法。比如：

線上出現(xiàn)嚴(yán)重故障，最終會調(diào)查追責(zé)到人，并施以懲罰；還是會分析故障原因，找出后續(xù)如何避免的改進(jìn)舉措呢？

如果是前者，一旦出現(xiàn)問題，所有相關(guān)人員會提心吊膽，很難客觀地分析和解決問題，反而會有某些隱瞞因素存在，導(dǎo)致下次可能還會重復(fù)出現(xiàn)類似問題。關(guān)于后者，之前在文章《缺陷分析如何幫助質(zhì)量內(nèi)建》中有關(guān)于故障/缺陷分析的詳細(xì)實(shí)踐，這里想要強(qiáng)調(diào)一點(diǎn)的是缺陷分析，分析到問題出現(xiàn)的客觀原因即可，無需追責(zé)到人。

一個非常典型的不追責(zé)例子是敏捷回顧會議所遵循的最高指導(dǎo)原則(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."
（“無論我們揭示了什么，我們必須理解并真正相信：考慮到當(dāng)時的已知情況、每個人的技能和能力、可用資源和情境，每個人都做到了最好。”）

-- Norm Kerth, Project Retrospectives: A Handbook for Team Review

不追責(zé)的另一面是鼓勵創(chuàng)新。成功來自于不停地試錯，要想把事情做好，需要不斷地嘗試，經(jīng)歷多次的不成功，并且在一次次失敗中總結(jié)經(jīng)驗(yàn)教訓(xùn)，從而獲得進(jìn)步。例如，高科技公司谷歌和亞馬遜，都是非常鼓勵創(chuàng)新的。

組織要宣揚(yáng)這種創(chuàng)新文化，給予員工適當(dāng)?shù)膭?chuàng)新空間，鼓勵大家積極地嘗試新點(diǎn)子，以不斷改進(jìn)軟件開發(fā)流程，提高軟件交付質(zhì)量。

1.3 全員負(fù)責(zé) vs. 獨(dú)立割裂

對于軟件開發(fā)團(tuán)隊(duì)來說，“團(tuán)隊(duì)對質(zhì)量負(fù)責(zé)”幾乎已經(jīng)是家喻戶曉了。但是，從組織級來看，團(tuán)隊(duì)該怎么定義？道理都明白，具體到實(shí)施層面，又是怎么做的呢？

據(jù)我所知的現(xiàn)實(shí)情況，部門與部門之間、團(tuán)隊(duì)不同角色之間還是比較割裂的，還有許多人認(rèn)為質(zhì)量主要是測試（部門/團(tuán)隊(duì)/人員）的事情，而業(yè)務(wù)負(fù)責(zé)業(yè)務(wù)需求、開發(fā)負(fù)責(zé)編碼、運(yùn)維負(fù)責(zé)線上就行了。

之前寫過幾篇團(tuán)隊(duì)對質(zhì)量負(fù)責(zé)的文章，歡迎移步閱讀：

• 《團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)，“我”可以不負(fù)責(zé)？》

• 《敏捷測試的指導(dǎo)性原則——團(tuán)隊(duì)對質(zhì)量負(fù)責(zé)》

• 《說好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢？》

從組織角度來看，需要明確質(zhì)量目標(biāo)，并讓全體成員知曉，以質(zhì)量目標(biāo)驅(qū)動各個職能部門間的合作，增強(qiáng)全員對質(zhì)量負(fù)責(zé)的意識。

? ?

2. 高效率協(xié)同

高效率協(xié)同強(qiáng)調(diào)的是組織結(jié)構(gòu)形式，以及組織內(nèi)各部分的協(xié)同方式，這是組織級測試體系構(gòu)建非常關(guān)鍵的一部分。

2.1 組織結(jié)構(gòu)

設(shè)計(jì)系統(tǒng)的結(jié)構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。

—— M. Conway（馬爾文·康威）

馬爾文·康威 1967 年提出的康威定律（康威法則, Conway's Law），即系統(tǒng)設(shè)計(jì)本質(zhì)上反映了企業(yè)的組織結(jié)構(gòu)。

軟件開發(fā)是一項(xiàng)復(fù)雜的社會活動，需要業(yè)務(wù)、開發(fā)、測試和運(yùn)維以及團(tuán)隊(duì)與團(tuán)隊(duì)之間等充分地溝通協(xié)作才能實(shí)現(xiàn)，根據(jù)康威定律，需要對組織結(jié)構(gòu)進(jìn)行相應(yīng)的調(diào)整以適應(yīng)軟件研發(fā)的需要。

而傳統(tǒng)的企業(yè)通常都有著非常厚重的部門墻，業(yè)務(wù)和科技之間，開發(fā)和測試、以及運(yùn)維之間，都分別屬于不同的部門，并且這種部門墻非常難以打破。這無疑是非常大的矛盾之處。

例如，傳統(tǒng)企業(yè)通常都有獨(dú)立而龐大的測試部門/測試團(tuán)隊(duì)，在獨(dú)立的測試階段來承接測試工作；在新形勢下要求持續(xù)測試，不再有非常獨(dú)立的測試階段，測試部門該如何調(diào)整以更好地與研發(fā)進(jìn)行高效合作是備受關(guān)注的問題，也是組織建立完善的測試體系需要解決的問題。

該怎么解決？比較常見的有兩種方式：

上面哪種方式比較好？很難說。

從形式上看，完成融合的第二種方式看起來是較好的，能夠?qū)崿F(xiàn)開發(fā)和測試更深入的融合，但是這對團(tuán)隊(duì)也是有很高要求的，需要在測試左移、團(tuán)隊(duì)對質(zhì)量負(fù)責(zé)等方面都做的足夠好，才能對于質(zhì)量有讓人放心的保障。因此，對于質(zhì)量要求非常高的行業(yè)，比如金融領(lǐng)域，比較容易接受的可能是第一種方式，一是因?yàn)閭鹘y(tǒng)的部門墻打破實(shí)在太難，還有很重要的一方面是還有獨(dú)立的測試部門對質(zhì)量“把關(guān)”，似乎能讓大家更放心。

至于自己的組織適合哪一種形式，還是需要組織自己去摸索。

2.2 團(tuán)隊(duì)拓?fù)?/strong>

組織應(yīng)該被視為一個復(fù)雜的具有適應(yīng)性的有機(jī)體，而非一個機(jī)械的線性系統(tǒng)。

—— Naomi Stanford，摘自《組織設(shè)計(jì)指南》（Guide to Organization Design)

《高效能團(tuán)隊(duì)模式(https://book.douban.com/subject/35528423/)》一書中指出組織結(jié)構(gòu)的陷阱：傳統(tǒng)的組織結(jié)構(gòu)圖是相對靜態(tài)的，并不能幫助我們理解組織中真實(shí)的溝通模式，在實(shí)際的軟件開發(fā)過程中可能有很多不依賴于組織結(jié)構(gòu)圖中所體現(xiàn)的溝通存在，這種適應(yīng)軟件開發(fā)的溝通結(jié)構(gòu)是更為關(guān)鍵而有價值的。因此，提出團(tuán)隊(duì)拓?fù)涞母拍睢?/p>

[《高效能團(tuán)隊(duì)模式》作者總結(jié)的團(tuán)隊(duì)拓?fù)銽eam Topologies](https://hennyportman.wordpress.com/2020/05/25/review-team-topologies/)

團(tuán)隊(duì)拓?fù)浞椒▏@企業(yè)軟件交付的有效團(tuán)隊(duì)結(jié)構(gòu)，帶來了一種全新的思維方式。提供了四類基本的團(tuán)隊(duì)類型：流動式團(tuán)隊(duì)、平臺團(tuán)隊(duì)、賦能團(tuán)隊(duì)和復(fù)雜子系統(tǒng)團(tuán)隊(duì)，以及三種團(tuán)隊(duì)核心交互模式：協(xié)作模式、服務(wù)模式和促進(jìn)模式。強(qiáng)調(diào)了在靜態(tài)的組織結(jié)構(gòu)（團(tuán)隊(duì)結(jié)構(gòu)）之外，更多地關(guān)注實(shí)際的溝通路徑，針對技術(shù)組織補(bǔ)充了傳統(tǒng)組織設(shè)計(jì)中所缺少的動態(tài)和感知方面的能力。

回顧前面提到的測試部門如何組織的問題，基于團(tuán)隊(duì)拓?fù)渌枷?#xff0c;我們可能會想到不一樣的解決方案，加強(qiáng)測試跟各個部門/角色的交互才是關(guān)鍵所在，需要根據(jù)產(chǎn)品開發(fā)需求構(gòu)建靈活適應(yīng)的團(tuán)隊(duì)拓?fù)浣Y(jié)構(gòu)，具體的組織形式或許不是最重要的。

2.3 溝通協(xié)作

團(tuán)隊(duì)拓?fù)鋸?qiáng)調(diào)了組織溝通結(jié)構(gòu)的重要性，在滿足溝通模式的團(tuán)隊(duì)構(gòu)建好之后，是不是就一定能實(shí)現(xiàn)相應(yīng)的溝通需求呢？也不見得。

例如，下面的一些情況可能大家都或多或少經(jīng)歷或者聽說過：

• 有些業(yè)務(wù)目標(biāo)、質(zhì)量目標(biāo)可能只是“高層”領(lǐng)導(dǎo)人員清楚，沒有對全組織、全團(tuán)隊(duì)透明；

• 有的企業(yè)，業(yè)務(wù)和研發(fā)團(tuán)隊(duì)坐在一起，但是溝通方式跟原來沒有區(qū)別，還是通過需求文檔來進(jìn)行溝通；

• 有的團(tuán)隊(duì)，測試和開發(fā)同屬于一個團(tuán)隊(duì)，但是測試不會參與開發(fā)的技術(shù)討論，開發(fā)有技術(shù)方面更新不會告知測試人員，開發(fā)不會參與測試策略和測試計(jì)劃的制定等；

• 同一個產(chǎn)品或者項(xiàng)目的不同小團(tuán)隊(duì)各自為伍，沒有知識和信息共享，導(dǎo)致重復(fù)造輪子的事情時有發(fā)生……

類似的情況可能還有很多。這些都是形式上貌似沒有問題，但實(shí)質(zhì)上缺乏有效的溝通協(xié)作。

關(guān)于溝通，首先要重視溝通的內(nèi)容，盡量讓信息在整個組織或者整個團(tuán)隊(duì)內(nèi)透明，尤其是關(guān)于愿景、目標(biāo)和風(fēng)險類的信息，可以增強(qiáng)成員使命感和主觀能動性。我在《敏捷測試的指導(dǎo)性原則》里介紹了高效合作的團(tuán)隊(duì)特點(diǎn)，在《警惕團(tuán)隊(duì)“蘑菇種植”》中也通過一些事例分享了信息共享的重要性。

另一方面，對于溝通的形式也要注意，不同的溝通形式所能起到的效果也是截然不同的。通常，面對面的溝通是最為有效的方式。如下圖所示：

協(xié)作建立在充分溝通的前提上，一旦溝通到位了，協(xié)作起來就會順暢很多。

? ?

3. 標(biāo)準(zhǔn)化指導(dǎo)

之前寫過一篇文章《敏捷團(tuán)隊(duì)的質(zhì)量保障賦能》，文中通過對 Google、Amazon 和 Facebook 等大公司的軟件開發(fā)交付流程的分析，總結(jié)了團(tuán)隊(duì)質(zhì)量保障賦能需要做到全流程的標(biāo)準(zhǔn)化。

通過標(biāo)準(zhǔn)化工作方式的指導(dǎo)，讓團(tuán)隊(duì)能更好地做到每個環(huán)節(jié)的質(zhì)量保障，更好地實(shí)現(xiàn)團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)。標(biāo)準(zhǔn)化一定要注意不要只流落于書面形式，參考《敏捷團(tuán)隊(duì)的質(zhì)量保障賦能》中的“事實(shí)標(biāo)準(zhǔn)與書面標(biāo)準(zhǔn)”。

3.1 研發(fā)流程的標(biāo)準(zhǔn)化

測試和開發(fā)是密不可分的，測試策略受到不同開發(fā)流程的影響。

不管是傳統(tǒng)瀑布式的開發(fā)流程，還是迭代式的敏捷開發(fā)流程，或者兩者相結(jié)合的開發(fā)方式，都需要將相應(yīng)的流程策略標(biāo)準(zhǔn)化下來，每個環(huán)節(jié)的活動有哪些，不同人員的職責(zé)分別是什么，都需要在組織級有清晰的定義。

在標(biāo)準(zhǔn)化的研發(fā)流程指導(dǎo)下，團(tuán)隊(duì)如果發(fā)現(xiàn)某個環(huán)節(jié)成為瓶頸，一定要詳細(xì)分析原因，如果是流程已經(jīng)不適應(yīng)新的團(tuán)隊(duì)現(xiàn)狀，也是需要調(diào)整和改進(jìn)的。

3.2 測試策略的標(biāo)準(zhǔn)化

針對不同的開發(fā)流程，需要有對應(yīng)的組織級標(biāo)準(zhǔn)化測試策略。組織級測試策略是個統(tǒng)一的指導(dǎo)方向，不同的產(chǎn)品線和不同的項(xiàng)目團(tuán)隊(duì)也需要有自主調(diào)整的空間，以更好地定制化適配的策略。

除了需要給團(tuán)隊(duì)自主調(diào)整策略的空間，還有一點(diǎn)要強(qiáng)調(diào)的是策略不是一成不變的，需要根據(jù)不同時期的質(zhì)量風(fēng)險和團(tuán)隊(duì)狀態(tài)進(jìn)行適配和調(diào)整，應(yīng)該是演進(jìn)式的。

關(guān)于測試策略，強(qiáng)烈推薦參考《一頁紙測試策略》，并根據(jù)所在組織自己的特點(diǎn)來定制化。

3.3 質(zhì)量目標(biāo)和度量策略標(biāo)準(zhǔn)化

清晰的質(zhì)量目標(biāo)能夠更好地驅(qū)動組織級測試體系的構(gòu)建。組織級的質(zhì)量目標(biāo)，一方面是純系統(tǒng)使用方面的質(zhì)量要求，更為關(guān)鍵的另一方面，應(yīng)該是跟業(yè)務(wù)目標(biāo)緊密關(guān)聯(lián)的，是需要以業(yè)務(wù)價值來驅(qū)動的。關(guān)于業(yè)務(wù)價值與測試，可以參考我的下列文章：

• 《業(yè)務(wù)價值驅(qū)動的測試》

• 《敏捷測試如何優(yōu)化業(yè)務(wù)價值》

談到質(zhì)量目標(biāo)，勢必需要相應(yīng)的度量指標(biāo)和度量策略，組織級需要對質(zhì)量目標(biāo)定義相應(yīng)的指標(biāo)，并且通過組織統(tǒng)一的度量策略來衡量。度量，特別需要關(guān)注的是不可以只看單一指標(biāo)，而應(yīng)該是綜合多個指標(biāo)衡量；也不適合將指標(biāo)作為產(chǎn)品線/團(tuán)隊(duì)橫向比較的標(biāo)準(zhǔn)，指標(biāo)應(yīng)該是指導(dǎo)產(chǎn)品線/團(tuán)隊(duì)自身持續(xù)改進(jìn)的尺子，非常同意 Thoughtworks 同事伍斌道長在他的文章《度量就是為了識別價值流最大瓶頸》中寫的：

“在敏捷 IT 研發(fā)交付中，度量的作用，就好比是在識別價值流中最大的堵塞點(diǎn)，以便在“價值準(zhǔn)、流速快、質(zhì)量好”這 3 個維度中，識別端到端價值流最大瓶頸（以及方向錯誤），并將其作為下一步改進(jìn)點(diǎn)進(jìn)行改進(jìn)，以最大化改進(jìn)成效。”

作者：吾真本
鏈接：https://www.jianshu.com/p/91eaf583ca3b
來源：簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

關(guān)于質(zhì)量度量，Thoughtworks 同事于曉南從定性和定量兩個角度進(jìn)行過非常詳細(xì)的分享，并且撰寫過一系列相關(guān)文章，歡迎參考她的《質(zhì)量度量文集》。

? ?

4. 規(guī)范化實(shí)施

在標(biāo)準(zhǔn)化策略的指導(dǎo)下，如何保證每個實(shí)踐活動都能做到位是個比較難的問題：有的實(shí)踐可能一開始就實(shí)施錯了；或者剛開始是正確的，但是過了一段時間，實(shí)踐就變味兒了……

規(guī)范化的實(shí)施方案是對標(biāo)準(zhǔn)化策略落地實(shí)施的保障。組織級需要從以下幾個方面考慮各個實(shí)踐活動的有效落地實(shí)施：定義實(shí)踐活動規(guī)范、沉淀新的優(yōu)秀實(shí)踐、定制化成熟度模型、定期治理與持續(xù)改進(jìn)。

4.1 定義實(shí)踐活動規(guī)范

對每個實(shí)踐活動進(jìn)行清晰的定義，包括實(shí)踐的目標(biāo)、適用條件、參與角色、輸入輸出等，最好用實(shí)例化的方式詳細(xì)介紹整個實(shí)踐活動的內(nèi)容。可以采用畫布的方式對前面幾項(xiàng)列舉介紹，更加清晰直觀。

定義好的實(shí)踐規(guī)范是團(tuán)隊(duì)實(shí)施落地的參考，在團(tuán)隊(duì)實(shí)踐過程中，也鼓勵團(tuán)隊(duì)根據(jù)實(shí)踐經(jīng)驗(yàn)去完善每個實(shí)踐活動，實(shí)現(xiàn)持續(xù)的優(yōu)化。

4.2 沉淀新的優(yōu)秀實(shí)踐

團(tuán)隊(duì)在實(shí)踐過程中，也會摸索出一些新的實(shí)踐活動，建議將新的實(shí)踐活動分享給更多的團(tuán)隊(duì)，推薦大家試用，一旦得到多個團(tuán)隊(duì)的認(rèn)可，可以將這個實(shí)踐活動也規(guī)范化，沉淀下來，存入組織級實(shí)踐庫中。

同時，對于一些不再適用的實(shí)踐活動，也要進(jìn)行淘汰和剔除。

4.3 定制化成熟度模型

基于實(shí)踐標(biāo)準(zhǔn)的成熟度模型，可以評估團(tuán)隊(duì)每個階段的實(shí)踐實(shí)施狀況，并制定相應(yīng)的改進(jìn)舉措，以幫助團(tuán)隊(duì)的不斷成長。組織級需要制定指導(dǎo)性的成熟度模型，供每個團(tuán)隊(duì)去定制化，以牽引團(tuán)隊(duì)的改進(jìn)。這塊內(nèi)容歡迎參考我的文章《測試成熟度評估》。

特別要強(qiáng)調(diào)一點(diǎn)：成熟度模型的目的不是用來評估，主要是為了指導(dǎo)改進(jìn)；成熟度如果要跟團(tuán)隊(duì)績效關(guān)聯(lián)，務(wù)必謹(jǐn)慎，不然就會陷入指標(biāo)陷阱。

4.4 定期治理與持續(xù)改進(jìn)

光有成熟度模型沒用，要能指導(dǎo)改進(jìn)，定期治理很重要。組織級層面需要制定定義質(zhì)量治理策略，落到每個團(tuán)隊(duì)來講，就是可以根據(jù)成熟度模型，定期對過去一段時間實(shí)踐落地情況進(jìn)行回顧，對現(xiàn)狀進(jìn)行評估，根據(jù)回顧和評估結(jié)果，并結(jié)合當(dāng)下的質(zhì)量目標(biāo)，制定新的改進(jìn)舉措。

比如，可以鼓勵團(tuán)隊(duì)根據(jù)迭代周期、發(fā)布周期等進(jìn)行定期回顧和治理；也可以根據(jù)改進(jìn)舉措的粒度大小，對不同舉措進(jìn)行不同周期的治理和改進(jìn)。

總之，組織級要有定期治理和持續(xù)改進(jìn)的意識，結(jié)合成熟度模型，鼓勵團(tuán)隊(duì)實(shí)現(xiàn)持續(xù)改進(jìn)。

? ?

5. 自動化支撐

強(qiáng)有力的基礎(chǔ)設(shè)施能夠?qū)|(zhì)量實(shí)踐活動落地實(shí)施提供自動化支撐，同步提升質(zhì)量與效能。

從測試體系構(gòu)建的角度來講，組織級需要全盤考慮幾個領(lǐng)域的自動化支撐：

• 流程管理：全生命周期的軟件交付流程，通常需要有流水線的支撐

• 測試框架：各種自動化測試框架，以及與持續(xù)集成流水線的關(guān)聯(lián)

• 數(shù)據(jù)分析：可視化各種數(shù)據(jù)及其分析結(jié)果，包括日志信息和度量指標(biāo)數(shù)據(jù)等

• 監(jiān)控預(yù)警：實(shí)時監(jiān)控團(tuán)隊(duì)和產(chǎn)品狀態(tài)，對質(zhì)量風(fēng)險和嚴(yán)重缺陷進(jìn)行智能預(yù)測和告警

只要聊到效能，大家腦海里就會冒出各種效能支持平臺和工具，這部分內(nèi)容是非常熟悉的，無需多述……不過，鑒于大家對工具平臺的熱衷程度，非常有必要提醒幾點(diǎn)：

1. 強(qiáng)調(diào)工具平臺的使用，但人員缺乏相應(yīng)的賦能，不清楚工具平臺背后的原理，從而無法高效使用。

平臺廠商和采購平臺的企業(yè)都有人跟我聊過這個現(xiàn)象，說明不是個例。工具平臺再好，也只有用對了才能事半功倍，不然就是個負(fù)擔(dān)。

2. 標(biāo)準(zhǔn)規(guī)范停留在書面上，根本沒有落地實(shí)施。

這就是前面提到的《敏捷團(tuán)隊(duì)的質(zhì)量保障賦能》中的“事實(shí)標(biāo)準(zhǔn)與書面標(biāo)準(zhǔn)”，而工具平臺是有助于將書面標(biāo)準(zhǔn)變成事實(shí)標(biāo)準(zhǔn)的。

3. 不同的團(tuán)隊(duì)采用不同的工具框架，組織沒有統(tǒng)一工具平臺的使用。

這將不利于不同團(tuán)隊(duì)間的協(xié)作和集成，不利于組織級數(shù)據(jù)的收集，會增加多余的成本。不要重復(fù)造輪子，能夠共享的工具平臺一定要在組織內(nèi)共享，一致的工具平臺對數(shù)據(jù)的收集和可視化都會帶來好處。同時，也要考慮團(tuán)隊(duì)優(yōu)先適配的問題，比如某個團(tuán)隊(duì)的自動化測試最佳方案是用工具 A，非強(qiáng)調(diào)要組織級統(tǒng)一，強(qiáng)制使用工具 B，那也是不合適的。萬事皆需平衡。

👀

? ?

03 組織級質(zhì)量賦能

根據(jù)前面介紹的測試體系圖譜，總體來說，組織級質(zhì)量賦能要著重關(guān)注以下幾個方面：

? ?1. 樹立適應(yīng)新時代軟件質(zhì)量要求的價值觀，營造全員重視質(zhì)量和價值交付的組織文化

隨著科技的持續(xù)發(fā)展，軟件生態(tài)日益復(fù)雜，新時代軟件質(zhì)量有著更高的要求，軟件質(zhì)量保障也面臨更大的挑戰(zhàn)，傳統(tǒng)的質(zhì)量保障、軟件測試的思路不能完全適合。而是需要改變傳統(tǒng)的認(rèn)知觀念，實(shí)現(xiàn)多角色深度融合、協(xié)同作戰(zhàn)、全員為質(zhì)量負(fù)責(zé)，重視質(zhì)量和價值交付。

? ?2. 朝著全流程標(biāo)準(zhǔn)化的方向前行，降低質(zhì)量成本

全流程標(biāo)準(zhǔn)化是大勢所趨，但一步到位也是比較難，分步走的策略才是可行的：

• 首先，定義組織級統(tǒng)一的流程策略，形成書面標(biāo)準(zhǔn)；

• 同時，制定實(shí)踐活動規(guī)范，以指導(dǎo)書面標(biāo)準(zhǔn)的落地實(shí)施；

• 通過部分團(tuán)隊(duì)實(shí)踐驗(yàn)證，逐步推廣并標(biāo)準(zhǔn)化固定下來，形成組織級標(biāo)準(zhǔn)；

• 利用工具支撐設(shè)置質(zhì)量門禁等方式確保書面標(biāo)準(zhǔn)能夠真正落地，并持續(xù)改進(jìn)和優(yōu)化策略標(biāo)準(zhǔn)和實(shí)踐規(guī)范。

? ?3. 強(qiáng)化質(zhì)量基礎(chǔ)設(shè)施建設(shè)，擴(kuò)大自動化規(guī)模，提升研發(fā)效能

大規(guī)模自動化是實(shí)現(xiàn)全流程標(biāo)準(zhǔn)化的有利助手，組織級測試體系需要從測試自動化和流程自動化兩個方向加強(qiáng)基礎(chǔ)設(shè)施建設(shè)，兩者缺一不可。

? ?4. 人員能力是關(guān)鍵，加強(qiáng)能力建設(shè)不容忽視

一方面，制定組織級人才培養(yǎng)機(jī)制，針對不同角色建立相應(yīng)的能力模型和提升路徑，形成人才梯度，有計(jì)劃地實(shí)現(xiàn)人員能力建設(shè)；同時，鼓勵社區(qū)建設(shè)，營造學(xué)習(xí)型文化氛圍，以促進(jìn)人員自主學(xué)習(xí)和提升。

關(guān)于測試人員能力提升，可以參考下列文章部分內(nèi)容：

• 《數(shù)字化轉(zhuǎn)型背景下的測試轉(zhuǎn)型》

• 《軟件測試人員該何去何從》

👀

? ?

04 最后

繼《基礎(chǔ)篇》針對測試人員的基本職責(zé)和《進(jìn)階篇》針對的全生命周期的質(zhì)量內(nèi)建之后，本《高級篇》通過介紹“一個中心，四個方向”的組織級測試體系圖譜，以幫助實(shí)現(xiàn)組織級質(zhì)量賦能。

至此，構(gòu)建測試的體系化思維系列的基礎(chǔ)、進(jìn)階和高級三個層次的內(nèi)容均已完成，希望能夠提供一個幫助大家思考的測試體系框架。