爲了避免逼瘋產品經理，咱們創建了一個缺陷管理！

一個有效的缺陷管理流程有多重要？我見過一些團隊並無一套有效的流程，而是經過口頭或者郵件的方式進行着缺陷管理，這些方式可能會致使許多問題，好比：

測試人員和產品經理說：咱們發現了15個Bug。

產品經理提交給開發人員了

過會兒，開發人員說：我修復了14個，另外一個不是Bug。

產品經理固然就又要提交給測試人員啦~

而後，測試人員說：有1個Bug沒有修復，另外我又發現了9個新Bug。

產品經理此時心裏是一萬隻神獸奔騰。

 

看得明白嗎？看不明白……看不明白就對了！若是沒有一個有效的缺陷管理，就僅僅是這樣口頭進行溝通，很快事情就複雜到誰也看不明白了，而後很快產品經理就瘋了……

因此，若是身爲產品經理你不想要瘋掉，那你就須要學會創建一套有效的缺陷管理。

那麼今天筆者就經過項目管理平臺——CORNERSTONE，爲你們演示如何創建一套有效的缺陷管理。

缺陷管理的流程

（1）準備工做：

建立測試用例

 

一個有效的缺陷管理，首先，測試人員固然不能是像上文那套場景中，想到哪兒測到哪兒，那咱這產品上線是期望不上了……因此在第一步，咱們要進入測試用例頁面，建立測試用例。

在CORNERSTONE中，企業可根據產品特性自定義用例模版，並補充優先級/狀態/責任人、添加描述、評論等操做，能夠說是至關的靈活方便。

建立測試計劃

 

有了用例，這還只是知道了測試人員要測什麼，接下來怎麼測還得明確一下，所以要建立測試計劃。

測試計劃是描述要進行的測試活動的範圍、方法、資源和進度的文檔。是對整個信息系統應用軟件組裝測試和確認測試。它可以肯定測試項、被測特性、測試任務、誰執行任務、各類可能的風險。測試計劃能夠有效預防計劃的風險，保障計劃的順利實施。

經過CORNERSTONE，用戶能夠在測試計劃中對責任人、優先級、狀態、分類、迭代、截止時間等屬性進行初始設置。

 

建立完成後，咱們能夠關聯編寫好的測試用例，方便測試人員操做。

記得曾經聽位老產品經理吐槽，說測試人員寫個項目的測試用例能有《莎士比亞全集》那麼厚。可見測試用例多難寫……不過好在咱們如今能夠藉助一些工具，好比說CORNERSTONE裏提供的測試與缺陷管理模塊，就支持將思惟導圖一鍵生成測試用例，這樣的設計能夠說是至關省心了~

 

（2）發現缺陷

 

萬事俱備，那麼測試人員就能夠開始測試了，測試人員根據CORNERSTONE的測試計劃頁中的內容進行測試，測試不經過，發現缺陷啦，快去缺陷頁建立一個缺陷吧……哪有那麼麻煩！在CORNERSTONE中，咱們能夠把測試用例關聯到缺陷中，只要直接把測試狀態爲「不經過」，缺陷就會自動更新狀態。下圖是一個比較常見的缺陷狀態流轉圖：

未解決

缺陷顯示爲未解決狀態，測試人員要將缺陷經過設置「責任人」，交給對應的負責人，對應的責任人將收到來自CORNERSTONE的缺陷變動通知，得~有得忙了……

拒絕

在CORNERSTONE裏，一樣也支持全部成員修改缺陷狀態，由於有時候開發人員會認爲提交上來的缺陷並非真正的缺陷，好比因爲緩存問題、網絡問題等，應將缺陷狀態標記爲「拒絕」，並附上說明，此時測試團隊須要從新測試或者提供更多的缺陷信息。

補充：使用CORNERSTONE的用戶可自定義缺陷的流轉過程的。

 

好比：

 

l  若是開發團隊收到的缺陷是重複的，或者與其餘正在進行中的缺陷問題類似，能夠標註爲「重複」。

l  對於部分不緊急的缺陷問題，比方說可能會隨着往後的產品迭代中進行修復，對於這類缺陷能夠標註爲「延期」。

待測試

當開發團隊修復缺陷後，應將缺陷狀態標記爲「待測試」，交給測試人員再次進行測試。測試不經過，測試人員再次將狀態更改成未解決，並添加說明。

關閉

在測試經過後，缺陷狀態修改成「關閉」或者完成。

你看，缺陷管理這樣來走，什麼「還剩一個是否是Bug」的，在走流程的過程當中已經獲得處理了。

 

設置合理的缺陷處理優先級

剛纔在講解流程的時候咱們提到一個關鍵詞「優先級」。咱們都知道，軟件產品就中的缺陷是難以免。 這些缺陷有輕有重，有一些缺陷若是沒有獲得及時和有效的解決，可能會形成很是嚴重後果，而另外一些輕微的缺陷，即使沒有修復幾乎全部人都不會注意到。

對於這些缺陷，咱們真心不必去浪費時間，除非你有無限的資源來分配好全部的缺陷修復任務，不然你須要優先將資源集中投資回報的缺陷修復上。

制定一套缺陷處理準則

要高效的處理缺陷問題，就須要創建流程，要創建流程，就須要有制定一套團隊間通用的缺陷處理準則。這樣，咱們不用再對每個缺陷問題進行詳細的評估，而是能夠直接按照咱們制定的準則，經過管理工具快速處理。

 

下面這一套缺陷等級準則範例，你們能夠參考，並依據自身的實際狀況來設置本身的等級標準。

l  低：可有可無的問題或某些功能不可用，但有一個簡單的解決方法

l  中：輔助功能不可用，但有合理的解決方法

l  高：重要功能不可用，但有一個合理的解決方法

l  嚴重：數據丟失、數據損壞或系統不可用

 

而後，咱們就能夠根據優先級別設置缺陷處理準則：

嚴重：必須當即處理，插入到當前的產品迭代版本中，高於其餘需求開發。

高：快速處理，插入到當前的產品迭代中，可是低於部分本次迭代需求開發任務。

中：處理，能夠隨着下一次產品迭代進行處理。

低：選擇性處理，根據迭代進度可放入下次迭代或者下幾回迭代中進行處理。

這種方法的關鍵優點在於，它大大減小了用於討論如何處理每個缺陷的時間。另外，團隊考慮的兩個因素影響範圍和嚴重程度是相對客觀的，減小了咱們因爲主觀因素帶來的偏差，讓衡量標準更容易判斷，也就能夠更簡單和高效的制度缺陷處理優先級別

關於如何創建一個缺陷管理，就和你們分享到這兒。

最後不得不說，衆多缺陷處理完成後團隊須要有數據支撐，以及時的發現問題，解決問題，改進缺陷管理流程。同時，能夠很好的衡量團隊工做成果，工做進度，檢測產品各個模塊的缺陷變化趨勢等。所以，一款好的缺陷管理工具應該有多種維度的數據報告能全局查看修復狀況，有效預防風險。

 

真是應了那句話「工欲善其事，必先利其器」，一個有效的缺陷管理，離不開一個方便的實用的管理工具。由於有它的協助，測試缺陷管理的每個環節變得更加清晰直觀；由於有它的協助，咱們能夠更快速、更精準地處理缺陷，提高產品品質。

CORNERSTONE

全行業覆蓋的一站式項目協做平臺

官網連接，收好不謝！

http://www.cornerstone365.cn