如何提高團隊開發質量

　　年輕的時候去面過一個相對於當時我的比較高階的管理崗位，當時的我情況是，開發經驗相對豐富， 但管理經驗還欠缺。對方當時面臨一個具體的問題。 

　　「我們最近生產上，出現了一個比較嚴重的事故，覆盤的時候，開發噴測試，測試噴開發，都覺得是對方的問題。對於類似情況你有沒有什麼解決和處理的經驗。如何提高軟體質量」

　　我當時對這個問題回答的比較單薄，無非就說，大家要團結合作，開發要加強自測，測試要考慮全面，有責任心。這麼說雖然沒錯，但是隻有戰略沒有戰術，也沒範例經驗。最終，顯然對方也不是很滿意， 無緣了這個崗位。

　　如今的我已不再是曾經的那個少年，雖然錯過的人已經錯過， 但問題長存， 都說人在不同的階段，對相同的問題，會有不同的答案，於是鍋叔在這裡重新回答一次……

　　具體這件事情，建議從三個層面來處理。　　

　　一、就事論事

　　這一層比較簡單，具體問題要具體分析， 要了解下這個問題的出現的原因， 歸屬的型別，然後才能明確責任。 一刀切的讓所有的生產Bug都由測試背鍋是不科學的。

• 如果需求明確，正向用例就應該覆蓋到，沒有被測出，那顯然屬於測試全責。進一步需要追查，這個部分的用例是誰編寫的，是否遺漏，執行了沒有，為什麼沒有測出。
• 如果屬於一些特殊資料，特殊流程下觸發的bug，不能認為全是測試的問題，開發也需要承擔部分。 可以具體分析下程式碼，是否屬於那種開發人員容易意識到而「有意忽略」的問題。實際開發經驗豐富的同學肯定容易理解，有些bug是，開發容易而且應該想到，而測試難以測出的。例如「並行減庫存」這類問題，僅通過功能測試很難測出，在開發設計時，就應該進行考慮。
• 也有可能存在開發，測試都很無辜，需求背鍋的情況，做出來的東西就不符合使用者的實際需要。或者需求，測試一起背鍋的情況， 需求調整需要連帶修改的需求，沒有做出調整，測試也沒有迴歸到。例如只考慮了新增輸入校驗，沒有考慮編輯已有資料的校驗等。

　　二、舉一反三

　　覆盤的目的，主要應該不是為了追責。而是為了優化流程。弄清事情的發生原因後，應該建立對應的流程，機制，避免類似的事情重複發生。例如，用例的執行應該能追溯，測試開發能力不足的，要培訓，要編寫對應操作規範等，缺少評審的流程加入評審。

　　三、統籌安排

　　如果公司覺得此事暴露了軟體質量的不足，期望改進開發質量，那麼就要理解，軟體的質量控制和軟體測試，其實是不同範圍的事情。質量改進包含的範圍遠大於軟體測試，對這一點要在團隊中進行宣貫，統一認識。

　　提高軟體質量不等於提高測試質量，質量控制是一個貫穿開發流程始終的活動，需要團隊的所有角色共同參與，為交付質量共同負責。

     　非常容易想到的一個職責是——不能理解錯使用者的原始需求，否則就將帶著整個團隊南轅北轍了，但這其實只是一個最基本的要求。

　　除此之外另一個重要的職責是——傳達清楚，即把需求全面，準確的傳達給使用者。

　　「準確」可以理解為要把你的需求描述清楚，條理清楚，避免歧義。實踐中很多bug的產生，是因為開發人員遺漏一些細節需求導致的。這類bug的情況，通常功能較為細節，例如一些細節的校驗，提示的文字，與同類功能的細小差異等。這類問題可以通過在需求編寫形式上上，使用逐一列出，重點強調的方式會比把所有需求無差別寫成一坨文字，降低發生的比率。歧義情況的出現，多是由於語言描述不嚴謹，不具體導致的，可以有意識多使用邏輯性描述，實踐所佔比例不高，適當注意即可。

　　「全面」實際是一個非常難以達成的要求，需要需求人員有較高的素質。這類問題造成的bug在執行維護多年，持續迭代的系統上暴露的非常多。抽象來說就是修改了某功能，要對應修改系統中對於此功能為有依賴的其他功能。對於陳年老系統，要考慮周全非常困難。簡單的例子如，為了增強賬號安全，增加了註冊使用者名稱的長度，也允許加入特殊符號。需求人員應該想到，此處修改除了影響使用者註冊頁面的使用者名稱輸入框校驗規則外，也同時需要修改，使用者登入頁面的使用者名稱輸入規則，如果有其他使用者端如行動端，也需要同步修改，如果後臺有使用者管理，搜尋，使用者名稱搜尋方塊允許輸入內容可能也要同步修改。甚至要求高的UI介面， 因為長度變化，可能會導致顯示異常，也要一併考慮到。

　　而產品架構，則是更高層次的要求， 要求需求人員對產品的功能，實體，概念，做恰當的抽象，並有一定前瞻性。 產品架構其實是技術架構的基礎，如果產品沒有一個需求上的框架，那技術架構也是無法恰當提出的，隨機應變會成為日常，修改成本會升高，穩定性會變差。 　　

　　 2、開發人員

  ·　　 開發人員主要是要強調自測，對自己的交付物負責。實踐中，開發人員常反懟說，我們又不是測試， 我們都測了要測試幹啥。 因此也確實涉及到一個度的問題。實踐中一個最基本的要求是， 對於需求對應的正向用例應該自測到，通俗說就是需求明確提到的功能開發自測應該覆蓋。例如「新增的使用者，點選使用者名稱稱，能夠顯示使用者詳情"，開發人員至少要保證自測下， 新增一個使用者，點選其使用者名稱，顯示詳情這個流程。如果沒有問題算通過。而測試人員則要考慮的更多。例如編輯的使用者，匯入的使用者能不能正常顯示？有特殊邊界輸入的，選填項不填的，顯示是不是正常。

　　情況往往也不會這麼簡單， 現代系統通常分工比較細，一個功能通常由幾個開發人員合作完成，他們之前通常通過介面定義來銜接，也就是各自按約定的介面協定，實現功能即可。這種情況下，除了要求按照介面自測外，還要要求，這幾個人中指定一個人負責串聯的測試，保證功能正確。因為實踐中介面難以定義的事無鉅細。 這裡的介面可能是前後臺間的http介面，也可能是基於資料庫表的介面（一個存，一個取）。如一個負責使用者存的開發只驗證了使用者資訊有沒有寫入資料庫表。 另外一個負責展示的開發人員只驗證了，自己在資料庫手動填寫的資料，能不能正常的被讀取顯示到頁面上。 如果沒人負責串聯驗證下這個過程，那介面對接環節的bug就無法發現，例如，存取的欄位不對應，空值的表示不一致null與""等。

　　開發人員自測確實可以更早的發現bug，降低bug修改的成本，不需要經過 ，「測試提」，"開發查"，"開發改","測試驗"的過程。但鍋叔覺得這只是開發自測收益中較小的一面，更大的收益在於，提高開發人員的質量意識，不是功能寫完就算是開發完。通過結合其他追溯機制，可以推動開發人員，使用更合理的設計，主動進行重構優化。

　　 3、測試人員

  　　測試人員在很多人的觀念裡，是天然的負責軟體交付質量的人員，其質量責任主要就是做「好測試」。做好測試，無非依賴於，紮實的軟體測試理論基礎，和對系統業務的充分理解。 測試理論屬於通用技能，只能通過學習思考，積累提高。而對系統業務的充分理解，對測試人員的穩定性是有一定要求的。 如果你們公司的測試人員是共用資源性質的，那應該儘量讓他們穩定服務於，1個或幾個專案。尤其對於長期迭代，週期較長的專案，人員穩定性非常重要，切換成本高昂。

　　質量控制是測試工作的超集，因此提高軟體質量，也要求測試人員額外承擔一部分質量分析統計工作。因為Bug直接由測試人員記錄產生， 由其來進行這類工作更為直接。常見的統計指標如，

　　用例通過率，重啟用Bug數，需求問題Bug數，未自測Bug數，遺漏需求Bug數，生產發現Bug數。

　　都是開發質量的評價依據，是覆盤優化的基礎資料。測試人員在測試工作中，或者生產環境支援過程中，在bug管理管理工具中，應對bug型別，進行識別歸類， 用於日後統計分析。

　　這也要求，測試人員要客觀公正，真實反應質量資料。這裡也提下，個人不贊成Bug與績效明確的掛鉤，否則容易造成開發測試對立，內耗嚴重，非常糟心。-_-||。

　　 4、管理人員

  　　管理人員，首先明白，研發有其自身遵循的客觀規律。所謂給技術以時間，凡事總有個測試，優化的過程，如果總是隨意拍腦袋，削減研發評估的研發週期，那麼，因為功能是顯而易見，一定要交付的，所以首先被壓縮的一定就是質量。例如一個系統計劃開發一個月，測試一個月， 領導一拍腦袋，開發測試壓縮成一個月， 那實際上，可能就開發3三個周，測試一個周，中間的各類評審也都被扔的七七八八，開發設計怎麼方便怎麼來， 測試就走走主要功能能用就行。這樣質量就不要苛責了，相當於把測試交給終端使用者，對於長期迭代的專案，也會累積不菲的重構債務。

　　建立評審，覆盤機制，是高階管理人員的職責。 重要的評審公司多小也應該具備，如需求評審，開發設計評審，測試方案/用例評審。同樣覆盤，如結項覆盤，或以時間為週期的月覆盤，季度覆盤。

　　基層管理人員，參與組織評審時，應保證評審不流於形式。如需求評審， 就是降低需求BUG的重要環節， 系統大了，需求人員自身的能力，也很難考慮的面面俱到，需要開發，測試共同，幫忙考慮，新需求對已有系統各處的影響。評審過程也是一個傳達質量價值觀的好機會， 在「好改，工作量小」和「規範，長遠可維護」中儘量選擇，規範的需求設計， 開發設計方案。要倡導細心和減少Bug是有非常有技術含量和挑戰的事情，而不是一件麻煩的事情， 讓開發多花精力在一次作對上。

　　 覆盤是一個重要的回溯機制，質量問題應該都能追溯到個人，誰提的需求，誰寫的，誰測的。 到不一定要跟績效掛鉤，但責任到人的方式，確實可以推動大家，建立質量意識，遵守質量規範。用例通過率低的模組的原因？需求Bug的數量較多，提示我們要重視需求編寫，評審，提高需求編寫人員能力，未自測bug多，提示開發人員責任心不強，生產的Bug數多，要分析，是否為常見問題，測試是否應該覆蓋，如果是使用者的日常操作，而回歸流程卻沒有納入，要考慮測試與使用者多溝通，瞭解使用者使用習慣。　　　

　　OK先到這裡，上面的回答，你給幾分 :-)。 

　　曾經有一份真摯的愛情擺在我面前,但我沒有珍惜,等到失去了我才後悔莫及,塵世間最痛苦的事莫過於此……o(*￣︶￣*)o