現在回頭看2016、2017年會發現那時候很多人熱衷於寫各種各樣的技術文章（包括我關注的測試技術文章），寫的也確實挺好，另外許多優秀的開源項目也是源至於那個時候，我是2016年進入現在的公司，現在細細品味公司的變化，我也發現了，2017年還真是互聯網的巔峯時期，從那以後就開始走下坡路了，進入2019年幾乎讓很多人感到陣陣寒意，這時候你去搜索一些自動化測試、性能測試、DevOps的文章，你會發現少了很多（好的文章大部分是2017年及之前寫的），因爲很多公司和團隊（包括QA、測試、運維團隊）都在戰略收縮，不再提什麼雄心壯志了。但正因爲這樣，我們才需要關注和反思很多事情，需要花心思去解決很多的技術債，欠債就得還，對於測試行業也是如此。我們測試和整個研發團隊，所面對一個最大的債，那就是產品質量。大家一路狂奔，造了那麼多輪子，生產了那麼多汽車，當面對去庫存壓力時，不應該重新想想什麼是質量什麼是口碑嗎？所以2020年我們將重點關注什麼是質量，關注如何提升質量，關注如何用最少的成本去提高質量，這可能也是來年大家的努力方向。而一個團隊中，誰該爲質量負責呢？很多人說是測試，而我接觸的測試人員裏不少會埋怨需求和開發，開發人員也同樣沒少怪到需求頭上，所以值得反思。
以下轉載一篇有關質量的文章並做了點修改，原文：http://www.sohu.com/a/337468907_487103
-誰應該爲質量負責？
-QA是負責測試把關，主要負責吧，DEV也要在設計和代碼上對質量負責。
-那其他角色呢？
-BA還好吧，跟質量的關係沒那麼大。
-……
在藍鯨項目，似乎大家對質量的關注意識有些欠缺，於是在項目上的不同角色、不同工作年限的人之間採樣做了一次訪談，上面這個問題就是其中訪談的問題之一。有同事曾提醒我說這種題就是送分題，肯定不會有人回答不出。可是，事實並非如此…
爲什麼會這樣呢？我猜想可能是大家對質量的理解不一致的緣故，在沒有搞清楚什麼是質量的前提下，當然也沒有可能理解到底誰該爲質量負責。
因此，我們來看看質量到底是什麼？
質量是什麼？
產品質量不是檢測出來的，從產品生產出來後質量就已經在那了。
——著名的質量管理專家戴明
在講什麼是質量之前，我們有必要區分兩個不同的概念：測試只能檢測、發現缺陷，而質量要通過缺陷預防來實現。 測試與質量不可同日而語，以後再也不要說“上線這麼多問題，測試是怎麼測的”這種話了。
那麼，質量到底是什麼？對於不同的角色、不同的利益相關者，質量有着不同的含義。總的來說，可以分爲外部質量和內部質量兩種。
1. 外部質量：
顧名思義，外部質量就是軟件呈現給用戶的外部形態，是否有缺陷、是否穩定、是否有性能問題等。也就是最終用戶在軟件使用過程中的各種體驗，包括軟件可學習、高效、不易出錯、有用、難忘等特性，都屬於外部質量範疇。外部質量也可以稱爲使用質量，主要是從使用軟件的用戶角度來看的。
外部質量能夠被用戶直接感知到，直接影響用戶的使用，因而顯得特別重要，客戶/用戶一般也比較容易爲外部質量買單。
2. 內部質量：
同樣的，內部質量就是指軟件系統內部的質量狀態，包括代碼的效率、結構、可讀性、可擴展性、可靠性和可維護性等。內部質量主要從開發人員角度來看，也稱爲代碼質量。衡量的5個標準包括Sourc Lines of Code (SLOC)、Bugs per code_section / module / time_period（Bug統計指標）、Code Coverage（代碼測試覆蓋率）、Design / Development Contraints（設計規則和代碼規範標準）、Cyclomatic Complexity（環路複雜度），這些衡量軟件質量的標準都是可自動化的。
內部質量不會被最終用戶感知到，不容易被客戶/用戶買單，也常容易被團隊忽略。但是，內部質量會影響外部質量，需要團隊引起重視，加強設計、開發等環節的質量把控。而且這部分通過自動化方式去檢測和衡量，其投入產出比也是最高的。
3. 內建質量：
質量不能被檢測出來，要提高軟件產品的內、外部質量，都需要通過質量內建（或質量內嵌）的方式，做好每個環節的質量保障工作。質量內建包含自動化測試和手動測試：
- 自動化測試：從多個層次（單元、組件、端到端等）寫自動化測試，並將其作爲部署流水線的一部分來執行，每次提交應用程序代碼、配置或環境以及運行時所需要軟件發生變化時，都要執行這些測試。同時，隨着項目業務和技術架構的演進，自動化測試策略也需要隨之調整、不斷改進。
- 手動測試：手動測試也是很關鍵的部分，如需求驗證、演示、可用性測試和探索式測試等，在整個項目過程中都應該持之以恆的做下去。
另外，質量內建不僅要考慮功能測試，對於跨功能測試同樣是需要做到內建的，比如安全內建、持續性能測試等。另外質量內建還要需關注軟件部署質量（對安裝包、部署說明書、自動化部署腳本、CI/CD或Pipeline質量、Docker質量等）。
軟件構建過程中多大程度上做到了質量內建，有多少缺陷做到了提前預防，這是“內建質量”。內建質量雖然跟內、外部質量不在一個維度，但也是體現質量好壞的一個方面，在此也把它作爲衡量質量的一個維度，測試或使用過程中發現的缺陷數量可以作爲度量指標。
因此，我們可以從這三個維度來度量軟件產品的質量，可以通過以下方式來度量：
外部質量：用戶反饋、Support的問題數量
內部質量：code review、結對編程、靜態代碼質量檢查（或自動掃描）
內建質量：測試環境、生產環境缺陷，Support的反饋
瞭解了三個維度質量的含義，我們不難理解：
- 質量不是零缺陷，不是百分百的測試覆蓋率，也不是沒有技術債；
- 質量是快速反饋，任何改變能夠快速驗證，並且快速修復；
- 質量是把精力都集中在正確的事情上；
- 質量是團隊在代碼、設計和交付上有信心做出改變；
- 質量是團隊對任何改變負責。
容易忽視的質量
從前面對質量的定義，廣義的質量其實包括軟件產品交付流程中的方方面面，每個環節的一點疏忽都可能對軟件質量造成不同程度的影響。下面列舉一些從項目上經歷的對質量關注有所欠缺的內容：
- 需求分析過程倉促，或者參與人員角色比較單一，導致業務上下文了解不夠，關鍵場景缺乏考慮等；
- 忙於交付更多的feature，忽略了對代碼質量的關注，該重構的沒有重構，在原本不太健康的代碼基礎上繼續增加更多的代碼，導致混亂，築起高高的技術債；
- 沒有足夠的測試覆蓋，導致新增代碼容易破壞已有功能；
- Dev提交代碼後，就投入新代碼的開發，對所提交代碼缺乏關注，CI pipeline紅了不能及時修復，可能影響後面QA的測試進度；
- 大面積的重構發生在release前夕，無法全面迴歸，帶來很大的風險；
- 項目初期只考慮少量用戶的場景，隨着業務的發展，系統功能難以擴展，導致嚴重性能瓶頸；
- 技術選型失誤，開發困難，沒有及時改進，一錯再錯，最後問題嚴重到無法彌補；
- 第三方組件評估不夠充分，導致線上環境無法承載等；
- 開發缺少對異常情況的處理，測試過程缺乏探索，只覆蓋到主幹路徑，邊角case可能引發問題；
- 開發或者測試都只考慮當前功能模塊，缺乏更廣範圍的考慮；
- 缺乏跨功能需求的關注，導致嚴重的安全或者性能問題；
- 對線上環境瞭解不夠，而且沒有足夠日誌信息記錄，線上問題難以定位，導致宕機時間過長；
- ……
這樣的問題還有很多很多，無法一一枚舉。每個角色，每個環節都有可能出現紕漏，導致產品質量問題。
那麼，誰該爲質量負責是不是已經很清楚了？
誰該爲質量負責？
在敏捷模式下，質量是貫穿項目整個生命週期的非常關鍵的部分，質量保障工作自然也是需要在每個環節有所體現。
上表列出的各個實踐活動都與質量有關，每個活動都要求多個不同的角色同時參與。
下面從敏捷團隊三個主力角色BA、QA和Dev的不同視角來看看各自怎麼爲質量負責。
BA：Busines Analyst，業務分析師（也叫需求分析師）
BA主要負責業務需求的分析工作，要理解客戶的業務，並將業務分解成便於Dev和QA理解的功能點，同時，還要能夠幫助用戶驗證開發完成的軟件系統功能，並展示給客戶。需求作爲軟件開發的源頭，是極爲關鍵的。
BA視角的質量，主要是需求分析的準確性和清晰度，要幫助團隊對需求有一致的認識，從用戶旅程的角度關注交付給最終用戶的產品是否真的帶來了價值。
Dev：Developer，開發人員
Dev作爲軟件系統實現的主力，對質量內建是至關重要的。從需求的理解、整潔的代碼實現、測試覆蓋率的保證、頻繁的代碼提交、持續的集成、對生產環境的關注、運維的支持等方面，都有着不可替代的職責，每個環節都不可忽略。
因此，Dev視角的質量不僅是按照需求實現功能的開發，還要把功能高效的交付給最終用戶。
QA：Quality Analyst，質量分析師
QA作爲軟件質量的倡導者，是唯一一個全流程都要參與的角色，從需求到上線後的支持，每個環節都不可缺。清晰理解需求、制定質量保障策略、做好各個環節的測試工作（手動、自動化、探索式、跨功能、非功能測試，以及生產環境的QA等）、關注項目整體質量狀態、及時反饋質量信息給團隊、識別業務風險和優先級、幫助優化業務價值，這些都是QA的職責。
三個主力角色中的BA一般都會有從用戶旅程的角度去考慮，其實Dev和QA也需要同樣的思維模式，不能把story或者AC割裂來看，而是要從整體的用戶旅程的角度、端到端的去考慮需求的實現和測試工作。
除了三個主力角色，團隊還有其他角色也都是要對質量負責的，比如：架構師要負責項目架構的健康，基礎設施負責人要管理和維護好基礎設施以保障開發和運維工作的順利開展，PM要管理好團隊的交付節奏、團隊成員的工作狀態、客戶的滿意度等，這些都是跟質量相關的。
寫在最後
質量不僅是某個角色的事情，團隊每個成員都撇不開質量這個話題。團隊爲質量負責要求所有質量角色都將質量推向看板的左側，從每個用戶故事的開始就將質量融入其中。
軟件開發生命週期的每個環節、每個實踐活動都不可輕視，只有在每個點上都做好質量的工作，才能實現真正的高質量交付，每個角色對此都有着非常重要的職責。
而作爲質量管理團隊來說，軟件質量標準的精細化與可自動化是我們繞不開的話題，最終的目的就是爲了掃除人的障礙，讓相關職責人員負起相應的質量責任。