產品上線後出現重大bug,責任應該歸誰?

一個成功的產品需要整個團隊,包括產品,設計,開發和測試人員的共同努力。任何一個環節薄弱,上線的產品都會存在瑕疵。產品上線後出現重大問題,是整個產品團隊的問題,需要整個團隊一起扛,一味的推卸責任是沒用的。

如果公司的開發人員目前技術能力比較弱,測試工程師卻只是一味的要求開發人員寫好代碼,加強自測,減少side effect,而不思考自己如何在當前的情況下做好相應測試工作以保證產品質量,那是解決不了問題的;如果公司的測試人員只有一個人,而開發人員不從自己重視代碼質量、加強自測的角度去要求自己,每次修改一些小bug,做一些小需求都要求測試工程師進行全面的測試,那也是解決不了問題的。

開發和測試,如同左右手,只有共同協作,彼此站在對方的角度來思考,才能最終解決問題。

上面講的是開發和測試工程師應該具備的思維,那是否存在可行的方法論。首先要解決問題,杜絕類似問題再次發生,就需要定位到問題本身,一般來說,可以從以下幾個角度來討論問題。

  1. Bug產生的原因,分析bug為什麼會產生,這個環節很重要,因為這個問題弄清楚了,下次可以有效的避免類似問題再次發生;
  2. Bug發生的地方,如果是產品主要功能出現的bug,那測試工程師是不是太過講究測試效率而導致測試不到位?發布一個版本,不管只是做了一個很小的需求,還是只修復了一個bug,都需要對產品的主要功能以及其他相關的模塊進行充分的回歸測試,絕不能只是頭痛醫頭,腳痛醫腳;
  3. Bug的責任認定,一般來說,除了少數責任非常明確的bug之外,很多bug都是需要產品,開發,測試和項目經理共同承擔的,為了團隊的團結,沒有必要去追究哪個部門負主要責任;一般來說,如果開發修改了功能卻不通知測試人員測試,那是開發的責任,如果測試人員測試用例覆蓋不全,或者測試時降低了回歸測試的範圍,那是測試的責任。

一些小tips:

要讓開發工程師在負責功能開發的同時,也要保證產品質量,往往不夠現實,不說大部分公司都存在很多初級的開發工程師,就是全部換成高級工程師,也不能杜絕線上bug的發生。產品質量,不能要求開發工程師既當球員,又當裁判。測試人員平時不妨多關注下誰是bug大王,重點檢測下對方的功能,對很多中小公司來說,這或許是更行之有效的方法。

推薦閱讀:

《微服務設計》閱讀筆記(一)微服務
大多數時間你根本不需要那麼強大[隨想]
《微服務設計》閱讀筆記(五)分解單塊系統
如何選擇MT4平台搭建商?
當我們說軟體工程師的時候我們在說什麼

TAG:互聯網產品 | 軟體開發 | 測試工程師 |