在過去的幾個月，我做了一些實踐，通過整理、討論和分析項目上的Defects情況，來探索質量管理中的待改進點。最終發現，Defects實際上給質量管理帶來了很多的啟示。
當然，要討論Defects，首先要使團隊對Defects有一致的理解。我查了很多資料，也沒有找到對”Defects”一詞的明確定義，大部分人將”Defects”等同於“Bug”。
1947年9月9日，Grace Hopper發現了第一個電腦上的bug。當團隊在Mark II計算機上工作時，搞不清楚為什麼電腦不能正常工作了。經過深度挖掘，才發現，原來是一隻飛蛾誤打誤撞地飛到了計算機內部，從而引發了故障。從此，人們開始用“Bug”（原意是“蟲子”）來稱呼計算機中的隱含的錯誤。
然而，一個好的軟件產品，不僅要關注功能本身，還要關注其是否好用、是否安全、是否給用戶帶來良好的體驗、是否幫助用戶實現真正的業務價值。因此，從狹義上講，Defects是指軟件程序中存在的某種破壞其正常運行的問題或錯誤。從廣義上講，Defects還包含那些沒有達到客戶或用戶期望的質量問題。具體來說，Defects可以分為以下幾類：
- 程序錯誤: 指程序中存在某種錯誤，比如邊界、時區等問題，使得系統無法正常工作。
- 性能問題：指由於性能瓶頸所導致的系統缺陷。試想，作為用戶，如果你想要查看一個報表，卻需要花10分鐘來等待加載，你是否會放棄？
- 安全問題：指軟件安全漏洞，造成信息洩露、或使得系統數據或功能易受攻擊。
- 兼容性問題：指程序無法在不同的硬件平臺、操作系統、網絡環境等中正常運行。
- 功能與用戶需求不否：指軟件功能與用戶期望不匹配。比如，用戶期望造一個沙發，卻交付了個馬紮。
- 交互體驗不佳：指用戶使用起來不方便。譬如，電梯控制面板上的“報警”按鈕和“關門”按鈕緊挨在一起，你是否經常由於”關門”而誤觸了“報警”按鈕？再比如，你在網頁中填寫了一個長長的表單，點擊“提交”按鈕後，系統提示輸入信息有誤，卻並沒有告訴你錯誤的哪裡，你是會不耐煩地從頭查閱，還是乾脆放棄？
Defects的產生與應對策略
產品質量是團隊共同的責任，軟件開發是一個過程，任何環節都有可能產生質量問題，但每個環節的問題都應該選擇比較恰當的處理方式。
在敏捷開發中，我們以迭代的形式逐步完成產品的開發，每個迭代都能以一個可交付的軟件呈現給用戶，從而儘早地獲得用戶反饋，以保證我們交付的軟件是用戶真正期望的。在每個迭代中，我們所有的開發都基於用戶故事卡（Story），每一張用戶故事卡都將經歷Analyse、Design、Code、Test、Deploy的過程。
那麼，在敏捷軟件開發過程中，哪些環節都可能產生Defect呢？
正如上圖所示，Defect分別來自於Sprint階段、UAT用戶驗收階段以及真正的生產環境。其中，Sprint階段又細分為：不合理的需求、不恰當的設計、代碼及邏輯錯誤、Story卡測試過程中發現的問題、迴歸測試中發現的問題、以及非功能性測試發現的問題。
開發過程中不同階段的Defects，我們分別採用什麼樣的敏捷實踐來應對呢？
上圖以看板的形式展示了Sprint開發中Story卡片流動的過程，以及每個環節的敏捷實踐，這些實踐有助我們發現和改善質量問題：
- 不合理的需求: 由於QA往往有不同於BA的視角，提早與BA Pair完善Story AC (Acceptance Criteria）。此時發現的問題要及時補充到Story卡上。這樣，不僅能夠儘早地發現需求上的不合理或遺漏，還有助於QA深入理解需求、設計測試用例。
- 不恰當的設計：UX製作出酷炫的設計圖，卻並不一定是用戶真正期望的，或者技術實現的成本過高。因此，一方面，要在開發之前與用戶Review設計圖，並按照用戶的反饋及時更新；另一方面，在每一張Story卡開始開發之前，由BA、UX、QA及Dev一起Kick Off Story，通過討論和澄清，使得團隊成員對需求和設計達成一致。一旦發現問題，要及時更新Story卡和設計圖。
- 代碼及邏輯錯誤：單元測試、Code Review、Desk Check都是用來發現代碼及邏輯錯誤的有效手段。因此，開發提交代碼後，要先執行單元測試、只有當單元測試通過之後，才可以將代碼部署到QA測試環境；然後按照Story的AC逐條與QA和BA進行Desk check。除此之外，開發團隊要每天堅持Code Review，以便發現代碼邏輯及編碼規範方面的問題。這些過程中發現的Defects都應該儘快修復。
- Story卡測試中發現的問題：Story卡測試時發現的問題，無論其嚴重程度如何，基本上都要在當前迭代修復。QA可以與Dev面對面溝通，也可以將Defect添加到Story的Comment裡面，再將Story重新拖回In Dev狀態，或者在物理看板上添加一張物理卡片。但無論哪種形式，都需要在早會時提及，以便有效地跟蹤Defect進度。
- 迴歸測試中發現的問題：普遍來講，迴歸測試發現的問題，優先級要低於Story的開發。因此，QA需要在電子看板或者Defects管理系統中提交一條Defect記錄，然後與BA溝通，在最合適的時間Assign給Dev。但如果該Defect造成系統崩潰或者Block了某些功能的使用，就應該立即修復它。
- 非功性測試發現的問題：非功能性測試一般是在每個Release上線之前做，發現的問題也要在Release之前修復。同樣需要在電子看板或者Defects管理系統中提交Defect記錄，但要注意其優先級。
- UAT用戶驗收階段的反饋：在UAT階段，開發團隊向用戶Showcase，或者由用戶來做用戶驗收測試。此時，用戶會提出一些反饋。由QA和BA對這些反饋進行分析，如果是功能層面的問題，在看板上建成卡片，並在上線前修復。如果是需求層面的問題，就將其添加到需求列表中，以便安排在之後的迭代計劃中。
- 生產上的問題：生產上的問題優先級是最高的。但是與用戶反饋一樣，功能層面的問題要立即修復，用戶體驗上的問題要添加在需求列表中。
Defects對質量管理的啟示
Defects並不是獨立存在的，它或多或少反映出了項目管理和開發過程中存在的問題，這些問題都可能對質量產生影響。比如：線上問題的走勢，是否能夠反映出產品質量的變化；分析每個迭代Defects的數據及產生的原因，有助於發現開發過程中出現的問題，及時地進行風險把控。
我以自己所在項目為例，說一說Defects給質量管理和團隊管理帶來的啟示。
1. 通過線上問題走勢，分析產品質量的變化
2017年8月，我們接到A遺留系統，到10月份累計在生產環境發現歷史遺留問題21個。按照優先級，每個月修復一定的數量。截止2018年7月，發現的歷史遺留問題高達46個，只剩餘2個還未修復。Defects數量在減少，產品質量在逐步提升。
除此之外，我們對歷史遺留問題和新引入問題做了對比，這10個月的線上問題中，歷史遺留問題佔85%，新引入問題佔15%，可見仍有部分沒能在開發過程中發現，使其流到線上。要對這些問題具體分析：其嚴重程度如何、產生的原因是什麼、為什麼在開發過程中沒有發現、後續有怎樣的改進措施。 當然，最好能對生產上的“運維類問題”和“功能類問題”加以區分，以便採取更恰當的改進措施。
2. 分析迭代Defects情況，討論改進措施
除了分析線上問題，我還對從2017年10月-2018年7月QA提交的Defects情況做了一個統計，觀察每個月提交的Defects和修復的Defects情況。
從統計結果來看，2018年7月發現和修復的Defects數量均呈明顯的上升趨勢，達到歷史最高點。因此，有必要對7月份的Defects情況做一個詳細的分析，看看究竟是什麼原因導致了這些Defects。
我對這些Defects做了一個初步的分類，並利用Retrospective Meeting的機會，與團隊成員一起分析討論。發現產生問題的原因有以下幾個方面：
- 本次Release的Story Kick Off和Desk Check做的不夠好。有時候開發沒有Kick Off就直接按照自己的理解開始編碼，導致團隊成員沒有對需求達成一致的理解，做出來的功能出現偏差。有時候Dev將一堆卡壘在一起做Desk Check，這樣很難逐條覆蓋AC，從而將問題流入QA測試階段。
- 本次的需求比較偏技術，BA只能從業務的角度去編寫Story卡。開發同學為了追趕工期，沒能夠添加充分的Tech Task, 也沒能夠堅持Code Review，導致出現一些邏輯錯誤。
- 單元測試覆蓋率比較低。作為一個遺留的微服務系統，某些服務在之前從未重構過，代碼邏輯比較混亂，添加單元測試的難度大、成本高。因此一些本該單元測試階段就能發現的問題一直流到QA測試階段。
- 本次Release一共一個月時間，UI一直到最後一個禮拜才確定下來，期間反反覆覆的修改不僅花費了太多成本，還消磨了Dev的意志，導致出現一些本不該出現的Defects。
- 新人加入，項目工期緊，對上下文信息同步不夠，導致新開發的內容破壞了一些已經驗證過的功能。
這些原因充分說明了這段時間項目中存在的問題，我們對此逐條提出了具體的改進措施：
- 堅決執行Story Kick Off和Desk Check敏捷實踐，在每日站會時嚴格跟蹤每一張Story卡的進度。
- 預定一個定期會議，每天下午17:00 – 18:00進行Code Review，並每週一人輪班擔任Owner。
- 將單元測試覆蓋率可視化。同時，制定項目標準：對於新開發的內容，必須編寫並通過單元測試才能Desk Check；對於歷史遺留模塊，在技術債牆上添加技術債卡片，並於每週消化一個技術債務。
- 項目開發前期要加強與客戶和用戶的溝通，在Story開始開發之前，確定好UI設計，開發過程中儘量避免大的改動。
- 新人加入項目時，採用結對編程的方式完成開發。除此之外，每週在項目內進行一次技術分享Session。
當然，以上兩點只是我基於A項目舉的一個例子。實際上，Defects還給了我們很多啟示，比如，為什麼項目老是加班？為什麼有些模塊的Defects數量比較多？如何根據團隊成員花在Defects上的efforts，制定提升計劃？然而，每個項目的情況不一樣，我們應該基於自己的項目背景，由團隊成員一起分析深層次的原因，共同制定切實可行的改進措施，從而不斷地提高產品質量。
文／ThoughtWorks史湘陽
原文：https://insights.thoughtworks.cn/about-defects/
閱讀更多 ThoughtWorks 的文章
