這篇文章的靈感，來自前幾天技術交流羣討論的內容，也是廣大測試同學日常接觸最多但也最容易忽視的一點：bug根因分析。bug嘛，一說起來大家都熟，畢竟測試這個崗位，最初的時候，被稱爲“捉蟲者”。
軟件測試崗位工作的日常，就是執行用例驗證開發交付的軟件系統是否達標，存在哪些bug，然後提單子並跟進修復和驗證，說起來簡單輕鬆，做起來無聊乏味，難怪很多同學自嘲，軟件測試崗位就是一個“點工”。
如果僅是這樣看待軟件測試工作，那確實有點浮於表面。要做好軟件測試甚至質量保障工作，除了最基本的找bug跟進，還需要對需求有足夠的瞭解，熟練掌握研發測試流程和方法，並且還要靈活應用多種技術手段來輔導團隊提升整體的交付質量和過程效率，這纔是質量保障工作的核心。
既然提升質量是工作核心，那反過來理解，就是想辦法減少bug的出現，或者在bug出現後能更快的修復，這樣也能達到提升質量和效率的目的。
工欲善其事，必先利其器；欲利其器，必曉其理。同理，出現bug意味着背後存在多種原因，比如對需求的理解不夠完善導致實現的功能存在偏差，比如修復老問題引發新問題等等，這些原因都是引起bug的現象，其背後更本質的因素在於需求評審、技術實現方案、編碼規範、用例設計、溝通協調等多種因素。
只有從根本上找到bug出現的原因，才能更好的達到提升質量這一目的。特別是在當前這種降本增效的大環境下，對測試團隊來說，更需要的是性價比較高的解決問題的方法。
前幾年業內很火熱的做了很多技術和方法實踐，比如單元測試、自動化測試，然後以此爲基礎開創了各種維度的指標，即所謂的質量度量。表面來看，每個版本每次迭代甚至每次發佈每次代碼提交的質量一目瞭然，以此指標可以精準的得到哪個團隊甚至哪個開發的代碼質量差，然後通過OKR+KPI，即所謂的引導員工提升自己。
但實際上呢，投入瞭如此多的資源，做了各種平臺，質量真的獲得了明顯的提升嗎？以我的觀察，並沒有，線上問題該發生照樣發生。那能以此推論質量度量就是沒價值的嗎？也不盡然。
度量只是保障質量的第一步，質量一定是需要定量的標準的，否則就會陷入不可控的狀態。但僅僅度量是不夠的，這只是統計層面的分析，只能看到問題發生在哪裏，爲什麼產生了這個問題，還需要進一步分析。
要分析問題出現在哪裏，需要證據，各種質量度量指標的元數據就是很好的參照物。但與此同時，要對問題進行深入的分析，還需要工程師具備豐富的理論知識和實踐經驗，只有這樣才能更快的找到問題的根源。
舉個例子，某個正常的版本迭代，bug數量和reopen數量激增，如果從統計層面來看，可能是某個開發的代碼質量太差，可能是代碼合併衝突，也可能是開發沒有按照編碼規範進行實現，這些因素都有可能。但更深入的思考一下，如果只是某個版本bug數和reopen數激增，其他版本正常，那就要可能是需求層面出了問題。
比如需求描述不清晰，比如編碼過程中需求多次的大面積變更，比如研發資源被抽掉同時兼任多個項目的開發工作，這些也會導致交付的軟件質量不高。但是，這些因素在質量度量層面，是看不到的。
還有其他可能，比如項目的deadline一直在變化，項目指標在變化，但關於變化產生的影響，大家並沒有做好溝通，導致信息傳遞變形，最終影響了編碼質量，這也是一種因素。但同樣，在質量度量層面，依然看不到。
要提升質量和效率，最實用和最具性價比的方式，依然是bug根因分析。只有解決了最根本的問題，才能更有底氣的完成保質提效的目標。
說到根因分析，很多公司都會有所謂的問題覆盤，但遺憾的是，覆盤後的改進動作和落地結果，很少有人關注和不斷驗證。說到提升效率，大家往往想的是自動化測試；說到提升編碼質量，大家一窩蜂的跑去搞單元測試和研發自測，各種冒煙測試和質量門禁。
在我看來，大家好像在一段時間內，患上了頭疼醫頭腳疼醫腳的習慣。卻唯獨忘了去調查bug產生的背後真正原因。這也是爲什麼很多測試團隊開發測試平臺和各種自動化，最終無法落地的原因所在。
質量保障和提效比較合理的步驟是這樣的：
- 統計問題，收集數據和證據(日誌)；
- 開展根因分析，找到最底層最本質的問題；
- 思考解決問題的辦法，並進行調研論證對比；
- 找到適合自己團隊現狀的方案，進行快速落地驗證；
- 觀察一段時間，有效就擴大範圍，並且持續優化，如此反覆；
近兩年我寫了很多關於質量保障體系建設的文章，你說這是方法論也好，說太複雜無法落地也罷。站在我的角度，我認爲方法論依然是值得我們不斷學習並且深入思考的。兼聽則明，多看多想，然後找到適合自己的方式去落地解決問題，纔是最核心的。
當然，bug根因分析和質量的持續改進並不僅僅是測試團隊的工作，而是應該和其他團隊如運維、架構合作，一起來持續的對質量和效率進行改進和提升。畢竟對於技術團隊來說，線上高性能高可用不出bug，是大家一致的目標。
測試團隊在其中要發揮的作用，可以是牽頭者，也可以是輔助，更可以是整個技術團隊統一目標的調停者。