從0到1創(chuàng)建高效的產(chǎn)品缺陷管理流程(1):缺陷是什么? 如何建立缺陷管理流程?
在任何軟件生命周期中,軟件缺陷的出現(xiàn)幾乎是不可避免的。建立一套有效的缺陷管理流程的目的是為了減少軟件缺陷出現(xiàn)的幾率,并且大幅度降低由于軟件缺陷帶來的負(fù)面影響。對于缺陷管理流程的投資,可以大幅度的降低由于返工/修復(fù)缺陷導(dǎo)致的人力,財(cái)力和時(shí)間浪費(fèi),同時(shí)提升用戶的體驗(yàn)或者更多用戶留存與產(chǎn)品口碑,并且可以保障產(chǎn)品更準(zhǔn)時(shí)的交付。
在正式開始談?wù)摦a(chǎn)品缺陷管理流程建設(shè)之前,我們首先介紹下一些基本概念:
軟件Bug和缺陷有什么區(qū)別?
什么是Bug?
Bug最初是在軟件行業(yè)的計(jì)算機(jī)用語,是指由于錯(cuò)誤編碼導(dǎo)致的結(jié)果。
缺陷是什么?
缺陷的英文:Defect,缺陷是指不符合最初定義的業(yè)務(wù)需求,其覆蓋范圍高于Bug,除了錯(cuò)誤編碼外其他導(dǎo)致不符合最初定義的業(yè)務(wù)需求問題都屬于缺陷范疇。
這兩個(gè)術(shù)語Bug和Defect在英文中有非常細(xì)微的區(qū)別,但在行業(yè)中都是需要修復(fù)的錯(cuò)誤,因此一些測試團(tuán)隊(duì)并不對這兩個(gè)詞語做細(xì)分。
當(dāng)測試人員執(zhí)行測試用例時(shí),他可能會遇到與預(yù)期結(jié)果不一致的測試結(jié)果。
測試結(jié)果中的這種不一致被稱為軟件缺陷。這些缺陷在不同的團(tuán)隊(duì)中有不同的稱呼,如錯(cuò)誤,缺陷,Bug,問題等。
缺陷報(bào)告應(yīng)該包括的信息:
當(dāng)向開發(fā)人員反饋缺陷時(shí),您的缺陷報(bào)告應(yīng)該包含以下信息:
- 缺陷ID:缺陷的唯一標(biāo)識號
- 缺陷描述:詳細(xì)描述缺陷,包括發(fā)現(xiàn)缺陷的模塊的信息。
- 軟件版本:發(fā)現(xiàn)缺陷的軟件程序的版本號。
- 復(fù)現(xiàn)步驟:詳細(xì)的步驟,以及開發(fā)人員可以復(fù)現(xiàn)缺陷的屏幕截圖。
- 缺陷提交日期:提交缺陷的日期
- 相關(guān)文檔:通過相關(guān)的需求、設(shè)計(jì)、架構(gòu)文檔并對比,能夠讓人更容易理解,例如產(chǎn)品需求文檔,相關(guān)產(chǎn)品原型或者用例文檔等
- 提交人:由誰發(fā)現(xiàn)的缺陷。
- 缺陷的狀態(tài):缺陷當(dāng)前的修復(fù)狀態(tài),我們稍后將詳細(xì)介紹
- 修復(fù)人:修復(fù)缺陷的開發(fā)人員
- 缺陷關(guān)閉日期:缺陷被關(guān)閉/解決的日期
- 缺陷等級:描述缺陷對軟件程序的影響的嚴(yán)重程度
- 缺陷優(yōu)先級:優(yōu)先級與缺陷修復(fù)的緊迫性相關(guān)。嚴(yán)重程度優(yōu)先級可以是高/中/低,這取決于缺陷修復(fù)對應(yīng)用影響的緊急程度
如果沒有有效的缺陷管理流程會怎么樣?
其實(shí)無論團(tuán)隊(duì)是否有花費(fèi)時(shí)間和精力創(chuàng)建缺陷管理流程,缺陷管理流程總歸是會存在的,但這一流程并不一定有效,我見過一些團(tuán)隊(duì)并沒有一套有效的流程,而是通過口頭或者郵件的方式進(jìn)行著缺陷管理,這些方式可能會導(dǎo)致許多問題,下面我舉一個(gè)簡單的實(shí)例:
如果像上述的情況一樣通過口頭或者簡單郵件溝通進(jìn)行缺陷管理,很快事情會變得十分復(fù)雜,如果你作為產(chǎn)品經(jīng)理,想要控制和有效管理缺陷問題,您需要了解一個(gè)缺陷的生命周期以及如何建立一套有效的缺陷管理流程。
缺陷管理的流程
為了能夠有效的管理缺陷問題,你需要建設(shè)一套有效的缺陷管理流程,以避免上述示例中這種無序混亂的狀態(tài)。 本部分將指導(dǎo)您如何將缺陷管理過程應(yīng)用于項(xiàng)目中。管理缺陷可以分為以下步驟:
(1)發(fā)現(xiàn)缺陷:新建
一般缺陷問題有測試團(tuán)隊(duì)根據(jù)用例步驟進(jìn)行測試,如果不能正常通過用例則轉(zhuǎn)為缺陷問題。但是很多團(tuán)隊(duì)并沒有專門的測試團(tuán)隊(duì),因此創(chuàng)建問題缺陷的可能來自不同團(tuán)隊(duì)或者來自外部用戶提交的反饋信息。這些缺陷反饋其缺陷狀態(tài)應(yīng)該為“新建”。
(2)開啟
當(dāng)QA測試團(tuán)隊(duì)或者其他相同職務(wù)的團(tuán)隊(duì)確認(rèn)了反饋的缺陷問題后,比如可以復(fù)現(xiàn),則確認(rèn)反饋是一個(gè)缺陷,并等待分配給開發(fā)團(tuán)隊(duì)。
(3)分配
當(dāng)測試團(tuán)隊(duì)確認(rèn)缺陷后,應(yīng)該將問題分配給開發(fā)團(tuán)隊(duì)進(jìn)行缺陷定位和修復(fù)工作。
(4)拒絕
如果開發(fā)團(tuán)隊(duì)認(rèn)為提交上來的缺陷并不是真正的缺陷,比如由于緩存,網(wǎng)絡(luò)導(dǎo)致的部分文件加載失敗導(dǎo)致的問題等,應(yīng)將缺陷狀態(tài)標(biāo)記為“拒絕”并指派回測試團(tuán)隊(duì)。測試團(tuán)隊(duì)需要重新測試或者提供更多的缺陷信息。
(5)重復(fù)
如果開發(fā)團(tuán)隊(duì)收到的缺陷是重復(fù)的,或者與其他正在進(jìn)行中的缺陷問題相似,應(yīng)將缺陷狀態(tài)修改為“重復(fù)”
(6)延期
部分不緊急的缺陷問題,可能會隨著日后的產(chǎn)品迭代中進(jìn)行修復(fù)。對于這類缺陷應(yīng)當(dāng)標(biāo)注為“延期”。在這里要注意,并不是所有缺陷都需要立即進(jìn)行修復(fù)。每個(gè)缺陷問題在嚴(yán)重程度,影響范圍均有不同,因此優(yōu)先修復(fù)的等級也不同。我會在下一篇文章中單獨(dú)講解制定優(yōu)先級別的方法。
(7)等待測試
當(dāng)開發(fā)團(tuán)隊(duì)修復(fù)缺陷后,應(yīng)將缺陷狀態(tài)標(biāo)記為等待測試并由測試團(tuán)隊(duì)進(jìn)行測試。
(8)關(guān)閉
在測試通過后,缺陷狀態(tài)修改為“關(guān)閉”或者完成。
(9)重新開啟
如果缺陷修復(fù)后并沒有通過測試,應(yīng)標(biāo)記為重新開啟,并重新啟用分配流程。
重要的缺陷KPI指標(biāo)
管理學(xué)大師德魯克說過:你無法管理那些你無法衡量的事情。 缺陷管理也是一樣,你需要有一些可供參考的指標(biāo),以便衡量管理效果. 您可以考慮使用以下兩個(gè)簡單的指標(biāo)來衡量您測試團(tuán)隊(duì)的執(zhí)行效果:
- 缺陷拒絕率?(Defect Rejection Ratio, 簡稱DRR):(拒絕的缺陷數(shù)量/總測試團(tuán)隊(duì)報(bào)告的缺陷數(shù)量)*100%
- 缺陷遺漏率?(Defect Leakage Ratio, 簡稱DLR):(遺漏的缺陷數(shù)量/總的缺陷數(shù)量)*100%
下面我舉一個(gè)簡單的實(shí)例:
Bugout的測試團(tuán)隊(duì)在Bugout的一次產(chǎn)品升級測試中,發(fā)現(xiàn)了50個(gè)Bug并反饋給開發(fā)團(tuán)隊(duì),其中5個(gè)經(jīng)過核實(shí)并不是Bug。新版本上線后,收到與本次升級相關(guān)的問題反饋10條并確認(rèn)均為Bug。
缺陷拒絕率(DRR)=5/50=10%
缺陷遺漏率(DLR)=10/(50-5+10)=18.18%
DRR和DLR的值越小,測試執(zhí)行的質(zhì)量越好。 什么是可接受的比例范圍? 可以在項(xiàng)目目標(biāo)中定義和接受此范圍,也可以參考類似項(xiàng)目的指標(biāo)。
相關(guān)閱讀
從0到1創(chuàng)建高效的產(chǎn)品缺陷管理流程(2):如何設(shè)置合理的Bug處理優(yōu)先級
從0到1創(chuàng)建高效的產(chǎn)品缺陷管理流程(3):如果選擇一款Bug管理工具?
#專欄作家#
陳迪,人人都是產(chǎn)品經(jīng)理專欄作家。Testin云測SaaS運(yùn)營總監(jiān),Bugout缺陷管理產(chǎn)品運(yùn)營負(fù)責(zé)人,增長黑客,多年國內(nèi)和海外互聯(lián)網(wǎng)公司運(yùn)營經(jīng)驗(yàn),專注于SaaS和B2B企業(yè)服務(wù)行業(yè)。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Pixabay,基于 CC0 協(xié)議
- 目前還沒評論,等你發(fā)揮!