軟件質(zhì)量是什么？
軟件質(zhì)量是什么？
業(yè)界通常將軟件質(zhì)量定義為如下兩部分：
Functional Quality - How well software complies with or conforms to customer specifications.
Structural Quality - How software meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability.
質(zhì)量是個很抽象的相對概念，如果打個比喻的話，會覺得質(zhì)量和安全感有很多相似之處。安全感是什么？看不見摸不著，是不怕走夜路？不怕下水？抑或可以自在獨(dú)處？
每個人對安全感的要求是不一樣的，同一個人在不同的年齡段對安全感的要求也不一樣。襁褓中的嬰兒大部分都很怕和母親分離，因?yàn)樗麄兒湍赣H從生命開始的那一刻起就有了切不斷的聯(lián)系，他們怕離開母親獨(dú)自面對子宮以外的環(huán)境。有些人可能因?yàn)樾r候有溺水的經(jīng)歷，即便成年之后，也無法涉水，對河流，大海有難以言狀的恐懼。
同樣的，在不同行業(yè)，有不同的質(zhì)量標(biāo)準(zhǔn)。廣義上講，我們有食品質(zhì)量，有工程質(zhì)量，有軟件質(zhì)量等等。狹義到我們的軟件開發(fā)，即使同一產(chǎn)品，不同的用戶對產(chǎn)品質(zhì)量的高低感受肯定也是有個體差異的。
另外質(zhì)量像安全一樣是個相對的概念，一般情況下我們會認(rèn)為家里相對馬路上來說是更安全的。但這是一般大概率的情況下，但當(dāng)?shù)卣鸢l(fā)生的時候，空曠的馬路上也許就比家里安全多了。質(zhì)量也一樣，軟件質(zhì)量的優(yōu)劣，是需要滿足特定行業(yè)特定用戶群體的產(chǎn)品訴求，符合某一年齡段或者特定性別用戶的使用習(xí)慣，兼容大部分目標(biāo)用戶特定設(shè)備需求等等。
軟件質(zhì)量是一個抽象的存在
軟件質(zhì)量在線的時候我們是比較難察覺它的存在的，我們不知道它就存在于我們的每一次需求討論中、每一念的設(shè)計(jì)斟酌里、每一回車的代碼提交時。但是一旦有客戶抱怨產(chǎn)品不好用，或者發(fā)現(xiàn)產(chǎn)品缺陷時，質(zhì)量這個隱形的存在似乎就變得特別醒目。貌似跟我們的健康一樣，我們健健康康的時候，很少覺察到健康的重要性，快樂地熬著夜擼著串。但是一旦我們生病了，這要忌口，那要注意，我們驚覺原來健康和我們的一餐一眠，一時一刻的情緒都息息相關(guān)。
軟件質(zhì)量是各個質(zhì)量屬性的綜合
通常情況下，人們習(xí)慣說好的軟件質(zhì)量就是實(shí)現(xiàn)了客戶對軟件的所有需求。但是什么是需求呢？在敏捷開發(fā)環(huán)境下，我們用用戶故事來管理，溝通產(chǎn)品需求。而用戶故事我們通常會歸類為功能需求和非功能需求。
舉個例子，小區(qū)門禁系統(tǒng)通過人臉識別實(shí)現(xiàn)自動開門，這是個很明確的功能需求。滿足了功能需求我們就能說這個軟件的質(zhì)量很好了嗎？某天某位業(yè)主畫了個濃妝，或者剪了個劉海，該系統(tǒng)無法識別了，功能無法滿足了。你會發(fā)現(xiàn)，通常功能性需求和非功能性需求是交織在一起的，很多非功能性需求是為了輔助功能性需求的更好實(shí)現(xiàn)。軟件質(zhì)量一定是需要去界定質(zhì)量特性，及滿足這些特性應(yīng)該具備哪些質(zhì)量屬性。
再舉個例子，我們可以拿生活中送禮物這事兒來類比。比如情人節(jié)到了，我們或多或少會期望收到一份來自另一半的禮物。而且還期待對方能無需提示，主動自愿，悄咪咪地準(zhǔn)備一個自己心儀的禮物。把‘收到禮物’ 看作‘What’，那‘無需提示，主動自愿，悄咪咪地準(zhǔn)備’，就是‘How’。如果跟你說：錢都在你那里，你想買什么自己買就是了。毫無儀式感和主動性，這個禮物會讓人開心嗎？
質(zhì)量模型
作為一個媽媽（被迫營業(yè)的非專業(yè)的育兒家），我知道孩子的安全感是可以被定義為很多維度的：滿足感，可控感，信任感等等。而且這些不同的安全感有其特定的建立階段，例如一歲之前，如果孩子能得到父母很好的照顧，持續(xù)的慈愛，嬰兒的滿足感就能被適當(dāng)建立。我相信育兒專家們對孩子的安全感一定有更專業(yè)的系統(tǒng)定義、建立及評估方法。質(zhì)量也一樣，即使很抽象，具有行業(yè)差異，但是 IT 從業(yè)者從來沒放棄過對其進(jìn)行定義和評估，因此產(chǎn)生了各種不同的質(zhì)量評估模型。
Dromey‘s Quality Model
* ISO 25010
這些模型都在試圖將軟件質(zhì)量這個籠統(tǒng)而抽象的概念，細(xì)化成不同粒度的質(zhì)量要素和質(zhì)量屬性。
作為項(xiàng)目上的 QA，我們需要先根據(jù)產(chǎn)品特點(diǎn)和客戶需求梳理出目標(biāo)產(chǎn)品的質(zhì)量屬性，根據(jù)屬性去定義質(zhì)量指標(biāo)。再根據(jù)質(zhì)量指標(biāo)來指導(dǎo)開發(fā)流程，產(chǎn)品架構(gòu)，測試策略，測試活動，風(fēng)險(xiǎn)管理等等。
軟件質(zhì)量的形成
以上討論了軟件質(zhì)量是什么？那軟件質(zhì)量是如何形成的呢？要回答這個問題，需要先來看看什么是軟件交付以及軟件交付流程。
軟件交付
在敏捷背景下，我們會認(rèn)為軟件交付就是快速地把客戶的想法變成為高質(zhì)量的軟件交付到用戶手中以獲得商業(yè)價值。
軟件交付是一個流程，從最開始 PO 的一個想法抑或一個業(yè)務(wù)痛點(diǎn)開始到最后一個成型的軟件產(chǎn)品，中間會經(jīng)歷很多的活動。大概包括但不僅限于以下活動：
根據(jù)上面的討論我們可以看到軟件交付實(shí)質(zhì)上是一個復(fù)雜的團(tuán)體工程活動：
包含多個交付活動，活動之間存在極強(qiáng)的關(guān)聯(lián)性，上游不合格的工件很有可能就成了下游工序的阻礙。也有可能某個工件流經(jīng)了好幾個環(huán)節(jié)之后才得以發(fā)現(xiàn)有缺陷，以至于返工。
涉及多個角色，角色之間需要溝通，而角色之間又會由于成長環(huán)境、教育背景、工作經(jīng)歷、思考習(xí)慣等的差異導(dǎo)致認(rèn)知上的差異。
對應(yīng)軟件開發(fā)生命周期，我們可以看到如下的軟件質(zhì)量形成過程。質(zhì)量在開發(fā)的各個環(huán)節(jié)一步一步建立起來，同樣每個環(huán)節(jié)都是有可能直接或間接地貢獻(xiàn)缺陷。根據(jù)業(yè)務(wù)痛點(diǎn)或訴求，精準(zhǔn)的產(chǎn)品定位，正確的需求分析，完備無誤的需求實(shí)現(xiàn)，全面細(xì)致的需求測試等等活動才能構(gòu)建出一個高質(zhì)量的產(chǎn)品特性。
在我們的交付中，總是免不了由于人的認(rèn)知偏差導(dǎo)致的主觀或客觀的失誤，例如具備業(yè)務(wù)可行性但不具備技術(shù)可行性的需求，半年前設(shè)計(jì)的不具備可擴(kuò)展性的架構(gòu)導(dǎo)致的性能問題，由于單元測試缺失或不足導(dǎo)致在新特性開發(fā)過程中造成的對原有特性的破壞。按照來源分類， 缺陷通常會有如下來源：
需求問題導(dǎo)致的缺陷
架構(gòu)問題導(dǎo)致的缺陷
設(shè)計(jì)問題導(dǎo)致的缺陷
編碼問題導(dǎo)致的缺陷
測試問題導(dǎo)致的缺陷
發(fā)布問題導(dǎo)致的缺陷
集成問題導(dǎo)致的缺陷
不管何種開發(fā)模式，我們都認(rèn)同一點(diǎn)，軟件交付的任何一個環(huán)節(jié)都是有可能引入產(chǎn)品缺陷的。敏捷更強(qiáng)調(diào)在各個環(huán)節(jié)通過不同的活動和實(shí)踐去主動規(guī)避缺陷的發(fā)生。而且這些活動和實(shí)踐，需要頻繁地，持續(xù)地踐行，做到持續(xù)反饋；及時調(diào)整交付方式，優(yōu)先級，精準(zhǔn)定位產(chǎn)品價值和市場需求。
軟件質(zhì)量的多面性
軟件質(zhì)量是個很大的概念，它有很多張面孔，可以涉及軟件生態(tài)的方方面面。
可以是軟件的使用質(zhì)量(quality in use)，即最終用戶可感知的軟件質(zhì)量。
可以是軟件的內(nèi)部質(zhì)量(internal quality)，產(chǎn)品的架構(gòu)的合理性、可伸縮性，內(nèi)部代碼簡潔度、規(guī)范性、可讀性、可測性等。
可以是軟件的外部質(zhì)量(external quality)，即軟件的各種行為，使用軟件能做什么。
可以是流程質(zhì)量(process quality)，能力成熟度模型，AMA ( Agile Maturity Assessment)、更早的 CMMI (Capability Maturity Mode) 等等。
還可以是交付質(zhì)量(delivery quality)， 例如我們的 agile trade off，4-Key-Metrixs 。
Agile Trade-Off 圖片來自網(wǎng)絡(luò)
不同類型質(zhì)量之間的關(guān)系
對軟件質(zhì)量的類型有所了解之后，你可能會問：不同的軟件質(zhì)量類型之間的關(guān)系是怎樣的？
流程質(zhì)量，即一個團(tuán)隊(duì)軟件交付流程的優(yōu)劣，這里的優(yōu)劣是相對的，非絕對的，但優(yōu)劣的本質(zhì)在于：
是否能讓需求在交付過程中保真順暢地流轉(zhuǎn)？
交付的各種產(chǎn)物是否都有對應(yīng)的業(yè)務(wù)價值？
是否每種形態(tài)的中間物（故事卡，產(chǎn)品架構(gòu)，產(chǎn)品代碼，測試代碼，測試覆概率等）都有相應(yīng)的檢測和反饋機(jī)制？
一般項(xiàng)目在立項(xiàng)的時候就會去定義 Way of Working, 軟件工件在流轉(zhuǎn)過程中的 Definition of Done。這些都是從流程上去規(guī)范軟件開發(fā)，保證團(tuán)隊(duì)以正確的方式做正確的事，避免偏離航線。
內(nèi)部質(zhì)量，即產(chǎn)品架構(gòu)的合理性，可擴(kuò)展性，代碼的規(guī)范性，可讀性，簡潔度，組件重用等等，這些質(zhì)量屬性往往對客戶是不見的。內(nèi)部質(zhì)量除了和開發(fā)人員技術(shù)能力有關(guān)外，直接受流程質(zhì)量的影響。例如重構(gòu)，TDD，引入編碼規(guī)范和 lint 工具，code review 等等。內(nèi)部質(zhì)量通常與以下問題有關(guān)：
能在現(xiàn)有產(chǎn)品上直接快速演進(jìn)新特性嗎？
現(xiàn)有產(chǎn)品能有效支持短期內(nèi)快速增長的用戶量嗎？
業(yè)務(wù)邏輯和技術(shù)框架足夠解偶以滿足定期的更新維護(hù)嗎？
外部質(zhì)量，用戶通過軟件可以完成特定的業(yè)務(wù)任務(wù)，即當(dāng)執(zhí)行程序，或使用軟件的時候，軟件的具體行為。通常外部質(zhì)量即是滿足產(chǎn)品預(yù)先定義的業(yè)務(wù)需求，和內(nèi)部質(zhì)量相比，外部質(zhì)量的好壞會直接影響客戶對軟件的使用的。
使用質(zhì)量，是比外部質(zhì)量更大范疇的關(guān)于軟件可用性，易用性，易學(xué)性及用戶體驗(yàn)為中心的質(zhì)量維度。業(yè)界對使用質(zhì)量的評估，有專門的模型，例如 QUIM model。
綜上所述，流程質(zhì)量影響內(nèi)部質(zhì)量，內(nèi)部質(zhì)量影響外部質(zhì)量，外部質(zhì)量影響產(chǎn)品的使用質(zhì)量。例如：團(tuán)隊(duì)流程不順，會導(dǎo)致溝通不暢，會影響需求在團(tuán)隊(duì)里流轉(zhuǎn)時的保真性，導(dǎo)致需求的錯誤實(shí)現(xiàn)或是遺漏。反過來，采用什么樣的流程取決于團(tuán)隊(duì)對內(nèi)部質(zhì)量的要求，內(nèi)部質(zhì)量要求又取決于外部質(zhì)量甚至使用質(zhì)量指標(biāo)。例如：使用質(zhì)量有安全性要求，因此團(tuán)隊(duì)需要在故事卡準(zhǔn)備，接口設(shè)計(jì)，開卡，結(jié)卡，編碼，測試各個環(huán)節(jié)將此質(zhì)量指標(biāo)考慮進(jìn)去。
測試和軟件質(zhì)量
以上我們討論了軟件質(zhì)量是什么，軟件質(zhì)量的形成以及軟件質(zhì)量的類型。接下來我們再來看看，我們的測試活動和軟件質(zhì)量又有何種關(guān)系。
流程質(zhì)量
流程質(zhì)量基本沒有常規(guī)意義上定義的測試活動，主要是通過各種實(shí)踐活動來保證各個角色對于產(chǎn)品需求的理解是一致的，所有人 On the same page，做了正確的事。我們對于開卡、結(jié)卡， 迭代計(jì)劃， 迭代演示，結(jié)對，代碼評審的好處是毋庸置疑的。更有 CMMI (Capability Maturity Model Integration)， AMA（Agile Maturity Assessement) 等等，都是對流程成熟度進(jìn)行評估的模型。
那作為 QA，需要做到的就是幫助團(tuán)隊(duì)識別現(xiàn)有流程的痛點(diǎn)和風(fēng)險(xiǎn)，提出流程改進(jìn)建議，并推行更好的流程實(shí)踐在團(tuán)隊(duì)中落地。如此，QA 便能從流程質(zhì)量上幫助團(tuán)隊(duì)實(shí)現(xiàn)質(zhì)量內(nèi)建，以避免流程缺陷導(dǎo)致的產(chǎn)品缺陷甚至是項(xiàng)目風(fēng)險(xiǎn)。
內(nèi)部質(zhì)量
2019 年的 5 月份的時候，Martin Fowler 發(fā)布了一篇名為 ‘Is High Quality Software Worth the Cost?’的文章，里面對內(nèi)部質(zhì)量做了很好的解釋。也是這篇文章激發(fā)了我對于質(zhì)量的總結(jié)和探索，才有了今天的這篇文章。其中如下這個圖將內(nèi)部質(zhì)量對軟件交付的影響進(jìn)行了很好的可視化。
內(nèi)部質(zhì)量高的產(chǎn)品是更容易進(jìn)行長期的產(chǎn)品演進(jìn)迭代的，而且會以相對更低的成本進(jìn)行產(chǎn)品的升級迭代。犧牲產(chǎn)品內(nèi)部質(zhì)量，確實(shí)在短期內(nèi)可以獲得很高的交付速率，但對于后期新需求的開發(fā)是不利的，甚至為了某一新特性的實(shí)現(xiàn)必須重新架構(gòu)產(chǎn)品，調(diào)整前期已經(jīng)實(shí)現(xiàn)的功能特性。但同時在短期內(nèi)，團(tuán)隊(duì)需要花費(fèi)更多的精力來提升內(nèi)部質(zhì)量。具體的內(nèi)容，大家可以查看原文。
那我們?nèi)绾蝸硖嵘捅ＷC產(chǎn)品的內(nèi)部質(zhì)量呢？
質(zhì)量內(nèi)建，測試左移
Test Driven Development
Acceptance Test Driven Development
Code Coverage
Code Review
Pair Programming
快速反饋
Test Pyramid
CI/CD DevOps
質(zhì)量人人負(fù)責(zé)
Kick-Off
Elaboration
Shoulder-Check
Sign-Off
Bug Bash
以上保證內(nèi)部質(zhì)量的活動中，大部分都是工程實(shí)踐，即流程質(zhì)量。
這也是為什么敏捷倡導(dǎo)全員負(fù)責(zé)，質(zhì)量在形成過程中，測試人員能起到的作用更多是一個質(zhì)量大使的角色，而真正貢獻(xiàn)質(zhì)量的是交付中的各個角色。測試活動也不僅限于常規(guī)意義上的測試，而是一個更大范圍的校準(zhǔn)，對齊，驗(yàn)證和反饋。這就要求 QA 從質(zhì)量的角度，和交付中的各個角色進(jìn)行合作溝通，并在合適的時候?qū)λ说馁|(zhì)量意識進(jìn)行賦能。一支人人有質(zhì)量意識，開發(fā)人員都是 Test-Infected-Developer 的團(tuán)隊(duì)，從某種意義上說，是不需要特定的 QA 角色的，人人可以戴上質(zhì)量這頂帽子，踐行質(zhì)量保證的活動。
外部質(zhì)量
產(chǎn)品的外部質(zhì)量怎么來保證呢？前面已經(jīng)提到了像特性測試，驗(yàn)收測試，探索性測試都是對外部質(zhì)量很好的保證。包括我們的很多自動化測試類型也是對外部質(zhì)量的進(jìn)行自動化反饋機(jī)制，例如 E2E 自動化測試， UI 的視覺回歸測試，API 接口測試等。
除了這些常見的測試活動，我個人比較推薦的一個測試思想是的基于風(fēng)險(xiǎn)的測試（ Risk based testing)。作為項(xiàng)目的測試人員或者 QA，在項(xiàng)目上我們的首要職責(zé)肯定是幫助團(tuán)隊(duì)規(guī)避由產(chǎn)品缺陷導(dǎo)致的質(zhì)量風(fēng)險(xiǎn)。風(fēng)險(xiǎn)是一個可能會發(fā)生的問題，發(fā)生的可能性越大，影響越大，那么該風(fēng)險(xiǎn)的嚴(yán)重程度就越大。以潛在的質(zhì)量風(fēng)險(xiǎn)來指導(dǎo)測試活動的開展，能以最少的資源，規(guī)避最大可能的風(fēng)險(xiǎn)。
使用質(zhì)量
當(dāng)產(chǎn)品發(fā)布到真實(shí)環(huán)境后就正式地進(jìn)入到了使用階段。終端用戶在他們的設(shè)備上，他們的網(wǎng)絡(luò)環(huán)境下，他們認(rèn)為的產(chǎn)品目標(biāo)下去使用產(chǎn)品，用戶所感知的產(chǎn)品質(zhì)量就是使用質(zhì)量。使用質(zhì)量相對不能測試，或者說測試活動具備多樣性、不可預(yù)測性。
相較于常規(guī)測試，生產(chǎn)環(huán)境我們更傾向于收集日志，監(jiān)控預(yù)警，統(tǒng)計(jì)用戶行為，進(jìn)行用戶調(diào)查分析，或者A/B Testing。
在 2016 年的時候，Thoughtworks 技術(shù)雷達(dá)就提出了 QA in production，這個概念于 2017 年出現(xiàn)在 MartinFowler 的網(wǎng)站上。北京的林冰玉同事也專門對 QA in Production 進(jìn)行了非常詳盡的闡述 。
通過以上每種質(zhì)量和相應(yīng)的保障機(jī)制，我們不難發(fā)現(xiàn)，真正意義上的測試能保障的并不像我們想象的那么多。所以才有了戴明那句關(guān)于質(zhì)量和測試的經(jīng)典名言：
軟件質(zhì)量是無法通過測試做到真正的提升的，待到測試時，軟件質(zhì)量已經(jīng)在那里，它是在軟件開發(fā)生命周期中一步步構(gòu)建出來的。而測試活動，只能是一定程度的驗(yàn)證，質(zhì)量水平反饋，以推進(jìn)改進(jìn)的發(fā)生。
正因?yàn)闇y試和軟件質(zhì)量有如此關(guān)系，我們也通常如此總結(jié)：
軟件質(zhì)量不是
0 缺陷
零缺陷？不可能，只是沒發(fā)現(xiàn)而已，抑或?qū)Υ蟛糠钟脩魜碚f不算缺陷。
100% 自動化
自動化只是幫助我們實(shí)現(xiàn)質(zhì)量反饋的一種形式，并不能說有了很全面的自動化就能保證團(tuán)隊(duì)能交付高質(zhì)量的軟件。而且受制于技術(shù)棧，產(chǎn)品特殊性，抑或人力成本，100% 的自動化對很多項(xiàng)目基本是不可能的。這一點(diǎn)可以參看我之前總結(jié)的關(guān)于敏捷自動化測試。
QA 的責(zé)任
沒有技術(shù)債
敏捷測試
我們總說“質(zhì)量內(nèi)建，全員負(fù)責(zé)”，但是很多時候我們的客戶會問，為什么要 TDD？都 TDD 了，為什么還需要測試？為何有這些實(shí)踐？希望以上對質(zhì)量的討論解答了這些問題。
我在入職第一天就接受了 TW 的測試指導(dǎo)思想的洗禮，截取其中核心思想的部分，如下：
隨著敏捷的廣泛運(yùn)用和從業(yè)者不斷的實(shí)驗(yàn)探索，后來又相繼有了測試左移，測試右移，持續(xù)自動化等等敏捷質(zhì)量實(shí)踐。在 Thoughtworks 我們的 QA 同志們更是總結(jié)了一套敏捷測試宣言，這些實(shí)踐和宣言都是基于軟件質(zhì)量本質(zhì)在敏捷開發(fā)模式下的更進(jìn)一步落地和反思。
在敏捷開發(fā)模式下的質(zhì)量模型長什么樣呢？和傳統(tǒng)的偏產(chǎn)品本身的使用質(zhì)量評估模型相比，敏捷質(zhì)量模型，更強(qiáng)調(diào)流程和實(shí)踐的評估。這些都是因?yàn)槲覀冋J(rèn)同流程實(shí)踐是能帶來質(zhì)量由內(nèi)而外的提升的。
如果我們只是知道這樣做有好處，而沒思考為什么要這樣做，對于構(gòu)建高質(zhì)量的軟件也是一種團(tuán)隊(duì)級的意識障礙。
參考文檔：
https://www.academia.edu/3713846/Different_Software_Quality_Model
https://insights.thoughtworks.cn/qa-in-production-practice/
https://www.thoughtworks.com/insights/blog/agile-quality-management-model
https://insights.thoughtworks.cn/agile-testing-manifesto/