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