那些 “被消失” 的缺陷

前陣子在做團隊溝通時，發現了一件很有意思的事：部分測試人員和開發人員會私下達成一致，對於發現的缺陷，不再直接記錄到系統中，以 “提升” 交付質量。個人把這些缺陷理解為 “被消失” 的缺陷，因為它並沒有真正消失，只是從明面轉到暗面。相信很多團隊負責人也遇到過這個場景（背景可能各不相同）。

01

殺頭的生意有人做，虧本的買賣無人幹。

這些 “被消失” 的缺陷為什麼會出現呢？大概是有以下幾點原因：

短期的 “質量改善”：這些 “被消失” 的缺陷，會暫時減少被發現的問題總數，給相關方一種團隊交付質量在慢慢變好的錯覺，從而避免麻煩（不靠譜的度量設計要背大部分的鍋，不少團隊還是以缺陷為唯一指標來評估質量）

減輕短期壓力：在專案交付時間緊迫或開發過程中遇到困難時，這種行為可能會讓團隊成員覺得暫時緩解了壓力，避免了因問題過多而產生的焦慮感。畢竟看板上不斷上升的缺陷數會給大多數人帶來壓迫感。

更 “和諧” 的團隊氛圍：測試和開發的相處會更和諧，你好我好大家好，畢竟只是一份工作。

看起來，好像這種做法也還不錯。

02

但是，上面的那些 “好處”，都是短期的，讓人一時痛快的。沒有從根本上解決問題，還帶來了更多更大的危害。

危害 1：遮蔽風險，影響決策。這些 “被消失” 的缺陷會讓問題被隱藏，導致專案風險激增。因為研發還是需要花時間去處理這些問題，但是團隊不會考慮這部分時間的投入。因為明面上是沒有這些事的。整體的安排會出現偏差，研發還是私下抱怨時間不夠。

同時，無法從這些 “被消失” 的缺陷中發現團隊可能存在的方法或者流程問題，無法有效地改進，讓同型別的問題爆發的更多，陷入一個壞的迴圈中去（發現越多的問題，越不彙報，越不彙報，就無法從根本上解決問題，從而產生更多的問題。）。

當真實的問題暴露出來後，管理層不得不重新評估專案的質量，並採取補救措施。這不僅浪費了時間和資源，還可能影響到公司的其他專案。

危害 2：降低專案質量。不真實地記錄這些缺陷，意味著無法從流程上正常跟蹤這些問題，那麼哪些是解決了的，哪些是還沒解決？過段時間雙方都忘記了怎麼辦？等到後期重現了，解決問題的成本在增加，對外的影響在增加，只會降低最終的交付質量。不記錄！=已解決。

危害 3：增加測試的工作量。由於危害 2，測試人員就得加大回歸的時間，來保證那些 “被消失” 的缺陷真的被研發私下解決了，而不是忘記了。在後續做質量分析和過程改進時，這些資料沒有得到有效的分析，就得不到改進，增加的，還是測試人員自身的工作量。

危害 4：破壞團隊信任。“被消失” 的缺陷本身就是一種違規的操作，如果被上級領導發現，那就會埋下懷疑的種子。這裡可以造假，那其他地方呢？是不是還有看不見的地方被埋雷了？個人的職業素養也會被懷疑，從而失去晉升的希望。

03

這些危害並不是危言聳聽。但凡管理過過 10 人的團隊，都應該意識到其中的風險。那麼，如何避免這種情況的發生呢？個人會採用以下幾種方法

保持測試的獨立性：雖然現在不建議過多地區分角色職責，但是測試作為一項獨立的研發活動，需要保持一定的獨立性。在測試設計和用例編寫時，可以與研發做更多的溝通和對齊。但是在測試執行開展時，還是需要保持一定的獨立性，對於發現的問題要有自己的判斷，而不是與研發單點溝通，言聽計從。

強調質量文化：在團隊中強調質量文化的重要性，使每個成員都明白質量來源於各個環節的共同努力，“被消失” 的缺陷並不能體現交付質量的變好，澄清上面提到的幾點危害，讓團隊共同為質量負責。

同時，也提醒管理者，不能只看缺陷指標，否則，你會在這個指標中迷失。

定期審計和審查：定期對專案進行審計和審查，確保所有工作都按照規範進行，及時發現並糾正問題。這類問題其實不難發現。如果你發現不了，是你管理的失職。

“透明” 是敏捷管理的三大支柱之一，也是提供決策的基本要素。如果團隊的研發資料無法真實反饋當前現狀，如果團隊的成員不敢於透明研發過程資料，那做改進有什麼意義？測試人員要避免這種現象，管理者更應該警惕這種現象。

共勉。