年輕的時候去面過一個相對于當時我的比較高端的管理崗位，當時的我情況是，開發經驗相對豐富， 但管理經驗還欠缺，對方當時面臨一個具體的問題，
“我們最近生產上，出現了一個比較嚴重的事故，復盤的時候，開發噴測驗，測驗噴開發，都覺得是對方的問題，對于類似情況你有沒有什么解決和處理的經驗，如何提高軟體質量”
我當時對這個問題回答的比較單薄，無非就說，大家要團結合作，開發要加強自測，測驗要考慮全面，有責任心，這么說雖然沒錯，但是只有戰略沒有戰術，也沒實體經驗，最終，顯然對方也不是很滿意， 無緣了這個崗位，
如今的我已不再是曾經的那個少年，雖然錯過的人已經錯過， 但問題長存， 都說人在不同的階段，對相同的問題，會有不同的答案，于是鍋叔在這里重新回答一次……
具體這件事情，建議從三個層面來處理，
一、就事論事
這一層比較簡單，具體問題要具體分析， 要了解下這個問題的出現的原因， 歸屬的型別，然后才能明確責任， 一刀切的讓所有的生產Bug都由測驗背鍋是不科學的，
- 如果需求明確，正向用例就應該覆寫到，沒有被測出，那顯然屬于測驗全責，進一步需要追查，這個部分的用例是誰撰寫的，是否遺漏，執行了沒有，為什么沒有測出，
- 如果屬于一些特殊資料，特殊流程下觸發的bug，不能認為全是測驗的問題，開發也需要承擔部分， 可以具體分析下代碼，是否屬于那種開發人員容易意識到而“有意忽略”的問題，實際開發經驗豐富的同學肯定容易理解，有些bug是，開發容易而且應該想到，而測驗難以測出的，例如“并發減庫存”這類問題，僅通過功能測驗很難測出，在開發設計時，就應該進行考慮，
- 也有可能存在開發，測驗都很無辜，需求背鍋的情況，做出來的東西就不符合用戶的實際需要，或者需求，測驗一起背鍋的情況， 需求調整需要連帶修改的需求，沒有做出調整，測驗也沒有回歸到，例如只考慮了新增輸入校驗，沒有考慮編輯已有資料的校驗等，
二、舉一反三
復盤的目的，主要應該不是為了追責，而是為了優化流程，弄清事情的發生原因后，應該建立對應的流程，機制，避免類似的事情重復發生，例如，用例的執行應該能追溯，測驗開發能力不足的，要培訓，要撰寫對應操作規范等，缺少評審的流程加入評審，
三、統籌安排
如果公司覺得此事暴露了軟體質量的不足，期望改進開發質量，那么就要理解，軟體的質量控制和軟體測驗，其實是不同范圍的事情，質量改進包含的范圍遠大于軟體測驗，對這一點要在團隊中進行宣貫，統一認識，
提高軟體質量不等于提高測驗質量，質量控制是一個貫穿開發流程始終的活動，需要團隊的所有角色共同參與，為交付質量共同負責，
1、產品，需求人員的質量責任
非常容易想到的一個職責是——不能理解錯用戶的原始需求，否則就將帶著整個團隊南轅北轍了，但這其實只是一個最基本的要求，
除此之外另一個重要的職責是——傳達清楚，即把需求全面，準確的傳達給用戶，
“準確”可以理解為要把你的需求描述清楚，條理清楚，避免歧義，實踐中很多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
本文來自博客園，作者：鍋叔
轉載請注明原文鏈接：https://www.cnblogs.com/uncleguo/p/16435007.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/498954.html
標籤：其他
上一篇：如何解決git pull之后push的時候commit message校驗不通過的問題
下一篇：都有哪些較好用的專案管理軟體？