本篇為【從零開始學產品】系列課第1章第3節

歡迎到公眾號選單欄，獲取產品經理課程更多資料

 

“從開始到死亡，這是世間萬物的宿命嗎？”

“是的，連Bug都如此。”

 

--摘自【修真神界】第三千六百五十一章 為了女神寫Bug

（本書預計在2035年出版）

 

一 什麼是BUG的生命週期

 

世界上本來沒有Bug，程式設計師多了，
就創造出來了Bug了.

 

程式設計師為什麼要創建出Bug呢?
是為了要修復它們.
噢,那程式們修復了Bug沒?
當然,他們不但修復了Bug,還寫出來了更多的Bug
 

 

所以一個Bug到底是怎麼產生的呢?

是被【使用者】或者是【測試】或者是【老闆】首先發現的

當然,程式設計師也會發現Bug,但是他們往往在告訴你們之前就修復了它.

 

Bug其實一直都在,只是誰先發現而已.

 

而我們講的生命週期,是指記錄到我們的Bug管理系統中.

通常是指從記錄那一天起,我們認為Bug是被建立了(但他們其實早就存在了).

 

而生命週期,就是指他們存在多久,中間會經歷哪些狀態,最後的歸宿是什麼

(並不是每一個Bug都會被修復).

 

 

所以,生命週期就是指在Bug管理工具中,我們記錄下來的一個Bug被建立,指派,修復,複查,關閉的過程.

 

生命週期就是要講清楚:

Bug應該有哪些狀態,分別是由誰去觸發,參與的角色又是誰.

 

但是,通常情況下,Bug管理工具和Bug的真正狀態並不一致.

就像剛剛說到的,我們只是在Bug管理工具上新建了Bug,而實際上Bug可能存在很久了.

 

就好像,我只是開口說出來喜歡你.

而在你知道我喜歡你之前,你並不知道我喜歡你多久啦~

 

BUG的狀態

我們儘可能的讓Bug管理工具和Bug的真實狀態一致,所以一般也是用Bug管理工具上的狀態來代替真的Bug狀態.

 

知道Bug生命週期,對產品經理和測試人員,和開發人員非常重要,這是用來規範和約束測試團隊,研發團隊的重要流程.

 

通常,Bug的生命週期分成如下幾個了階段

 

新建

指派

接受

修復

關閉

這是一個簡單的Bug生命週期圖

也是一個非常理想的圖.

但實際情況不是這樣的~~~

讓我們接下來,依次去看一下每一個節點是怎麼樣的.

 

 

二 新建一個BUG

 

提一個Bug簡單麼?

上次我們提到了測試用例,有說到,測試用例要有前置條件.

其實,和測試用例的預期結果不一致的,都可以被稱之為Bug.

 

但理論上,你是不可能把所有的測試用例都寫完的.

一個原因是:

總有超出你預料之外的因素,或者是神操作出現.

另一個原因:

成本的問題,沒必要把所有的測試用例都寫清楚.

(沒點Bug上線,使用者會不習慣的,逃).

 

提BUG重要原則之一

所以,記錄Bug的第一個重要原則就是:

說出執行環境和操作步驟,並配上截圖.

1 執行環境
2 操作步驟
3 截圖

執行環境通常是指:

作業系統,瀏覽器版本,Android和IOS版本

廠商,當前執行的軟體版本,正式和測試環境等.

 

操作步驟簡要說明如下:

1.開啟房門準備入洞房
2.掀開紅蓋頭,
3.發現沒有美嬌娘,反而是一個好兒郎

 

錯誤截圖

 

期待結果

 

提BUG重要原則之二

第二個重要原則就是,說明是偶現還是必現.

這一點很重要,坦誠的講,如果是只是偶爾一次遇到

而經常會遇到

我..也不是不能接受啊!

這叫偶現,對於程式設計師來講,就代表著要追查的難度增加.

而必現,指的是至尊寶每次進洞房,都遇到的是如花.

(那他早把月光寶盒擼爛了吧.)

1 偶現 
2 必現

 

提BUG重要原則之三

第三個重要原則是,給出產生Bug的資料

很多時候,Bug並不是每一個人都會遇到的,而是只有特定的場景下,才會出問題.

只有某一個人才會出問題.

 

我們之前做公眾號的時候,就發現一個妹子一點就錯,後來才發現是妹子的名字有emoji表情符出錯.

所以在提Bug的時候,
要記著把測試時出現的資料提供出來,
方便程式設計師去拿這個資料複查.

 

提BUG的角色

最後說到,提Bug的角色,一般都是QA.

所以,無論是客戶,老闆,還是研發團隊自己,或者是使用者,
發現了bug,請直接反饋給我們的QA,
由QA統一錄入,QA才能知道,這些Bug是不是真實存在,
是不是和已有的Bug重複,
是不是開發人員已經在修復 ,
是不是使用方法不對,
是不是和需求一致.

更新過的角色圖是這樣的

 

三 指派

 

修復BUG

好了,我們已經完成生bug,呃,提Bug最重要的步驟.

現在問題只有一個啦,誰來修復?

喂,喂,你們別走啊,這個Bug誰修復啊?
....

所以,指派功能很重要.

QA需要提出Bug之後,把Bug指派給某一個倒黴鬼,啊,勇於承擔責任的人.

 

通常,研發團隊都會有指定的負責模組.

如果你知道是哪一個人在維護哪一個模組,你可以直接把Bug指派給他.

 

而大多數的時候呢,你不知道誰在負責什麼事,也不知道這個問題可能屬於哪一個人,怎麼辦?

 

不要試圖去弄清楚誰應該修復這個Bug,這不是你的職責.

前端會說,這是後端的,你指給後端吧.
後端會說,這是前端的,你指給前端吧.
前端會說,這是PM的需求,你指PM確認吧.

PM會說:???

Bug已經創建出來了,找不到人接手

(是不是好像寶寶生出來了,卻沒人承認是自己的孩子).

 

最好的方式就是指給研發團隊的小組Leader.

不管是前端還是後端,還是App端,或者是別的.
你能分清的,你就分給明確的負責人,你不知道是誰的.
你直接指給小組負責人,他可以很快的判斷出來,這個Bug應該誰修復,
他如果自己都不知道誰應該為此負責,就自己寫唄.

 

流轉與確認

指派這個環節,最關鍵的地方就在於,並不是只有一次.

通常,在Bug的確認過程之前,會流轉好幾次,在Bug的修復過程中,有可能會在不同的人手裡流轉好幾次.

這是Bug修復的正常狀態.

 

但是往往會發現一種情況,就是有人認為不是自己的Bug,又沒有及時把Bug扔出去.

最終導致的就是,Bug卡在他那裡,動不了.

 

因此,我們需要設定一個Bug的確認時間,還記得我們上節講的Bug的級別沒有?

Major級別以上的Bug,都要求在2個小時之內做處理,
要麼流轉,要麼接受.

Normal以下不超過2天.

這是需要大家按照自己的約定去調整的過程.

這是一個很關鍵也是很容易被忽視的過程.

指派可能會是以下幾種原因:

1.來自QA的指派
2.確認不是自己的問題,指派給下一個可能的人
3.屬於自己的問題已解決,但是還是需要其他人做下一步的處理.

指派的時候需要帶上描述,比如說:

"親,我這邊測試出來的結果是這樣的,沒有錯,你看一下,是不是你那邊可能出問題了?"

畢竟指派可能就是甩鍋啊.

指派是Bug流轉的重要環節,不要讓自己成為流程中的卡點.

 

那麼在圖上,應該是這樣的.

 

四 確認

確認與迴應

其實這個可以講的簡單一點.確切的來說:

指派是一個動作,新建的時候,Bug的狀態是未分配.

 

啊,之前講錯了我好難過.

但是算了,我們現在糾正過來~~

 

正確的狀態應該是這樣的:

這才完美~

[新建],[指派]這些是動作.

[新建]之後,是未分配的狀態.
通過[指派]的動作,變成已接受.

所以.當指派完之後呢.要先接受,表示好了,這個事我安排上了.

跟著就是可能會繼續指派.

這個時候不會更改已接受的狀態,不過Bug在誰手裡,都是在這種已接受的狀態.

 

這個狀態沒什麼可講的.

但是剛剛突然想到了,我原本是不想在這個時候提起的.

就是這個時候,研發團隊並不是只有接受的權利,實際上,還提供了其他可選擇的幾種狀態.

無法復現
設計如此
推遲修復
重複Bug

這是程式設計師們迴應QA的最好的武器,特別是無法復現.

當然,你要確定是真的無法復現,
不然測試小妹妹那邊就是不好,只是研發團隊可用,是沒有用處的.

設計如此是在嘲笑QA的智商.

推遲修復就是做排期,我知道應該修復但是我就是不想修復的代名詞.

重複Bug,就是在說你眼瞎麼我已經在處理一樣的Bug了.

所以,圖應該是這樣的.

 

五 已修復

 

誰優先

程式設計師修復Bug,是要有優先順序的.

正常來講,我們推薦兩種Bug的處理方式.

第一種.Major級別以上的Bug,立刻修復,停掉手裡的事情.

第二種,Major級別以下的Bug,
跟著下一期的版本正常修復,或者是單獨釋出一些小版本.

這裡的關鍵點在於:

第一要對Bug區分優先順序.
第二,要處理好修復Bug和當前所完成的專案之間的衝突.
第三,所有的Bug修復產生的對當前專案的影響,研發團隊自己承擔.

那麼,什麼時候應該標成已修復的狀態呢?

是在開發團隊在開發環境驗證之後.

 

關於開發環境,測試環境和線上環境的區分,我們會在下一節的課裡講清楚.

 

推薦的Bug變更成已修復的流程是:

開發人員在開發環境去給QA演示Bug已經修復完成了,
QA確認後,才去更改狀態.

 

誤區

注意幾個常見的誤區:

1.不要未修改狀態就釋出到測試環境
2.不要未演示就修改狀態

這兩點如果能夠把握好,對Bug的修復流程就會好很多.

 

六 已關閉

 

完成

那麼,當開發人員確定是修復完成了.什麼時候應該是改成已關閉的狀態呢?

Bug會有在兩個環境發生,一個是測試環境,一個是線上環境.

測試環境的Bug,就在測試環境驗證完成.

線上環境的Bug,第一時間看在測試環境能否重現,
如果可以重現,就在測試環境完成.如果不能重現,就在線上完成.

 

驗證

如果說驗證的時候,不通過,怎麼辦呢?

改成Reopen,重新開啟

(我不確定是否只在Bug關閉的時候才應該開啟它

但是一個Reopen的狀態就夠了,它和未分配其實是一樣的,只是用來標記一下

這是一個二婚).

 

七  小結

這一節重點講了Bug的生命週期.

以[未分配]為開始,以[已關閉]為結束.

像不像愛情?

以未婚而開始,以接受命運的指派而改變,
尋找真命天子,往返奔波,最終確認婚姻的殿堂,
接受生活的驗證,要麼白頭到老,要麼重歸單身.

這就是Bug的生命週期,也是愛情的生命週期.

可是存在沒有Bug的人生麼?

可是存在沒有Bug的愛情麼?

在愛情的世界裡,兩個人的分歧,到底是Major級別,還是Normal級別,又該用怎麼樣的方式來處理?

誰提出來的Bug,誰又能夠規定必須要在多久的時間內修復?

 

 

線上環境算是正式的婚姻麼?

測試環境算是談戀愛麼?

開發環境算暗戀或者是戀愛之前的懵懂?

 

誰才是真正解決你的愛情的那個人?

誰才是能夠和你明確你的愛情不屬於她的人?

 

如果你知道,愛情是有生命的.

那麼你就應該明白,Bug是同樣有生命的.

 

 

現在只剩下了一個問題.

我問了這麼多的問題,跟你一個單身狗有什麼關係呢?

還有,跟你一個已婚狗又有什麼關係呢?

趕緊提Bug,改Bug去吧~~~

 

第一章第三節的內容就到此結束

下節預告：

【三個環境：開發、測試、和線上】，敬請期待

 

歡迎來交流群與大家一起學習討論，在裡面進行實時的溝通答疑

 

微信分享人：

暗滅，出身搜狐，葡萄藤創始人/CEO，10年敏捷開發最佳實踐

 

駐場大神：

搜狐產品大神張春源：10年+產品開發經驗，高屋建瓴

冰秀大神：出身搜狐，連續創業，創業者的產品即是公司：一家被收購，一家上市，匠心獨運

 

想進群的請加大師姐微信邀請進群：

記得備註學產品喲