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