Bug管理的經(jīng)驗和實踐（下）

孟巖：劉振飛，你好。在這個系列的前面兩篇文章里，我們先是探討了Bug管理的理念和意義，然后又從軟件系統(tǒng)的構建角度更進一步探討了Bug管理技術層面的問題。這次我想我們應該來探討Bug管理中“人”的問題了。當然，所謂人的問題，就是管理制度的問題。有了先進的理念、堅實的軟硬件基礎，還需要有相應的管理制度與之相配套，否則Bug管理就只是一個擺設。你認為一個軟件開發(fā)團隊應當制定嚴格的Bug管理制度嗎？沒有一個相配套的管理制度，會有怎樣的后果？

劉振飛：我們在第一篇文章中討論過，微軟的軟件研發(fā)可以總結為以下兩點：

（1）．需求（PM）、開發(fā)（Dev）、測試（Test）三權分立，分工明確、各司其職

（2）．每個產(chǎn)品的每個版本遵循同樣的模式：流程＋工具＋人，并不斷反饋（以改進流程、升級工具并提高團隊/員工的能力）

       回到你這個問題，Bug管理制度其實就是定義Bug處理流程，有了好用的工具之后，我們需要這樣的流程去明確指導如何對Bug進行管理。但是一個軟件開發(fā)團隊應當制定嚴格的Bug管理制度嗎？坦率的講，不需要。嚴格的制度在軟件行業(yè)就意味著教條、負擔和不切實際，讓一幫聰明的大腦陷入無邊無際的條條框框不能自拔，明知道是包袱還要去背、是火坑還要去跳，直到有一天終于受不了，最終結果不外乎三個：過勞累到、對付一天是一天或者干脆辭職換個工作。因此我覺得應該用“Bug管理指導原則（guidance）”來替換“Bug管理規(guī)章制度（rules & regulations）”這個詞。

所以我認為Bug管理就是去制定適合自己團隊實際情況的Bug處理流程和指導原則，制定者（管理層）應該起到真正指導的作用，他們要非常清楚下面這些問題的答案：

l         我們需要測試什么：哪些軟件（網(wǎng)站）、哪些模塊

l         測試人員的分工：什么人負責什么模塊

l         測試工具和環(huán)境：巧婦難為無米之炊。你不能安排一個測試人員去測某個模塊，而沒有給他提供必要的軟硬件環(huán)境

l         測試的進度安排：干這一行加班是不可避免的，但是需要有度，人不是機器，長期的勞累誰都扛不住。如果時間很緊，那只能去抓重點，要有所不為

l         發(fā)現(xiàn)一個問題時，如何用Bug管理工具去創(chuàng)建一個Bug：標題如何寫、嚴重程度、詳細重現(xiàn)步驟、錯誤狀況、期望結果、現(xiàn)場附件、這個Bug去分配給誰

l         當一個Bug被處理掉時，測試人員應該如何驗證并關閉

l         當一個Bug的解決方法有爭議時，誰來仲裁

l         定期的Bug提醒，比如當前每個人的Bug情況

l         Bug狀態(tài)報告：Bug數(shù)目的變化趨勢及我們應該采取的行動

l         階段性的總結反饋：哪些地方我們做的好，哪些做的不好，為什么、如何改進

l         … …

沒有這樣配套的Bug處理流程和指導原則，再好的工具都將會是一個擺設、甚至是添亂的工具。就像一個樂隊有非常出色的各種樂器，但樂隊指揮是個外行（就像成龍電影《雙龍會》一個鏡頭），那么演奏出來的一定會是混亂的樂章。

孟巖：根據(jù)你的了解，國內中小型軟件開發(fā)企業(yè)中Bug管理制度方面有什么缺陷？主要的問題是什么？

劉振飛：我想目前中小軟件企業(yè)的Bug管理主要存在的問題是：

1.         不重視測試，認為測試人員無關大局，隨便測測就行了。當然這種情況正在逐步好轉，因為大家都開始意識到了測試重要性；

2.         有些企業(yè)，認識到測試的重要性后，卻走向極端 --- 制定了極其嚴格的規(guī)章制度：無數(shù)瑣碎、難用的測試工單、非常嚴密的一級級權力控制，在Bug管理系統(tǒng)中誰能看到什么信息、誰可以解決、誰可以關閉等等，非常嚴格。一個需要靈活變化的工作變成了工業(yè)制造車間流水線的一個工種，讓測試人員陷入制度的泥潭，不能把主要精力投入測試工作本身；

3.         管理層自身沒有制訂明確的Bug處理流程及相關指導原則，讓測試人員在黑暗中摸索，走到哪兒算哪兒，不能給他們以切實有效的指導和幫助；

4.         管理層把軟件的質量保證責任一股腦推到測試人員身上，任何問題都去指責下面的測試人員，殊不知測試僅僅是研發(fā)的一個環(huán)節(jié)，前面需求、開發(fā)兩個環(huán)節(jié)如果沒有好好做，測試將會極其被動，比如：沒有需求文檔，怎么測試？這是一個系統(tǒng)工程；

5.         錯誤的考核標準：管理層用Bug個數(shù)去衡量測試人員的工作成績，誰發(fā)現(xiàn)的Bug多誰的工作就做的好。這是一個十分危險的傾向，將直接導致測試人員去重視Bug個數(shù)這個數(shù)字本身、而不是產(chǎn)品的真正質量。

遺憾的是，即使在微軟內部，各個地方研發(fā)中心也有這個傾向，比如經(jīng)常出現(xiàn)大陸、臺灣、韓國、日本四個地方某個軟件的測試人員虎視眈眈的在半夜盯著某個版本的問世，一旦下載到最新的Build，馬上安裝測試，把表面上的Bug趕快“搶”到、記錄進Raid/Product Studio中，然后心滿意足的打車回去，很高興比另外三個對手多上了幾個Bug。我記得微軟內部有個專門的培訓曾認真的研討過這個問題：不能用Bug數(shù)目來衡量Tester的工作。但是微軟太大了，當某地方或部門不能找到更合適的標準的時候，Bug數(shù)目本身就是最快捷的答案了。

這是我現(xiàn)在經(jīng)常思考的問題之一。

孟巖：能否請你比較系統(tǒng)地闡述一下微軟的Bug管理制度？

劉振飛：其實前兩篇文章已經(jīng)陸續(xù)談過微軟的Bug管理指導原則了，這里系統(tǒng)的總結一下：

u       管理層要求所有的Bug都要通過Raid（Product Studio）來跟蹤處理。這個看起來很簡單的Bug管理工具是每個員工和其他同事有效協(xié)作的重要保證

u       每個產(chǎn)品都細分模塊（Area，SubArea），每個模塊都有明確的需求定義者（PM）、開發(fā)工程師（Dev）和測試工程師（Tester）這三個角色。一個問題出現(xiàn)了，一定會落實到某個人的頭上去跟蹤處理，絕不能出現(xiàn)“無主”的Bug

u       PM負責書寫的Spec是這個功能特征（Feature）的“合同”，以此Spec來指導開發(fā)和測試。當Dev和Tester就某個Bug發(fā)生爭執(zhí)的時候，PM負責給出一個明確的說明

u       測試不僅僅是Tester的事情，盡管那是他們的專職工作。研發(fā)團隊中的所有人每發(fā)現(xiàn)產(chǎn)品的問題時候，都有義務把這個問題告知負責這個模塊的測試人員去記錄跟蹤這個Bug，或者干脆自己新建一個Bug來跟蹤

u       你可以創(chuàng)建一個Bug指派給自己，以跟蹤某件事的處理。比如開發(fā)人員把源代碼中的某處問題用Bug記錄下來，以后抽出時間來進行處理

u       團隊中的所有人都可以創(chuàng)建、指派和更改Bug的狀態(tài)

u       當你創(chuàng)建一個Bug的時候，描述一定要足夠詳細，讓下面處理Bug的人和其他關心這個Bug的同事能夠通過Bug描述準確的重現(xiàn)這個問題，而不是猜測某些步驟或者跑過來當面問你

u       通常一個Bug的處理過程是這樣的：

1.         Tester發(fā)現(xiàn)一個問題，到Raid中創(chuàng)建一個Bug，描述這個Bug的詳細信息，比如重現(xiàn)步驟（Repro Step）、錯誤結果（Result）、期望的改動（Expect）、運行版本等；然后把這個Bug指派給負責該模塊的Dev Lead

2.         Dev Lead判斷后把這個Bug指派給某個特定的Dev

3.         Dev處理掉這個Bug并返還給原Tester，或者請求PM給出一個澄清說明

u       管理層通過Raid來跟蹤整體進度，以及每個員工、團隊在其中的貢獻

u       有專人定期給相關同事發(fā)出Bug的狀態(tài)報告

u       每個人都可以方便的自助查詢Bug的分布處理情況。Bug管理系統(tǒng)對所有的團隊成員都是毫無保留的敞開大門（除了你不能刪除Bug，另外所有的操作都被忠實的紀錄下來）

u       隨著時間的推移，管理層要逐步給出明確的Bug解決指導方針：哪些Bug是可以不理睬的（Won’t Fix），哪些是可以推遲到下個版本處理（Postponed）。比如在最終Build到來前的幾周，也許非常嚴重的Bug，像數(shù)據(jù)丟失、程序崩潰之類的也都要推遲到下個版本再解決了。

u       當一線員工出現(xiàn)爭執(zhí)、無法達成一致意見的時候（盡管這種情況不多見），管理層要快速給出處理意見

等等。

孟巖：在微軟，如果違反了這些制度，會有什么后果？

劉振飛：哈，這個問題有意思。我還真沒有仔細考慮過，如果一個研發(fā)人員在微軟違反了這些“Bug管理制度”，會有什么結果？他一定不會因此被開除J，不過他肯定會努力學習和適應這些Bug處理原則，他的直接上司也會指導他如何做才是正確的。

       讓我們換個角度去考慮這個問題。Bug管理是研發(fā)管理的有機組成部分，而研發(fā)管理是微軟企業(yè)管理極其重要的部分，只有好的企業(yè)管理才能把業(yè)務做好，業(yè)務做好了，公司就有好的利潤，這樣公司發(fā)展了員工也跟著賺錢了。微軟可以很奢侈的在眾多求職者中招聘到合適的員工，這個員工進來后不可能對微軟近30年研發(fā)總結出來的“Bug管理制度”發(fā)生抵觸情緒、甚至有意去違反破壞這些處理原則，他所能夠做的只能是快速去體會、理解、適應這些流程和指導原則。

       我曾聽到這樣一個故事：國內某大型軟件企業(yè)研發(fā)老總訪問微軟，詢問如何進行研發(fā)管理，微軟一位研發(fā)高層答曰：很簡單啊，定期看看Email發(fā)來的Bug報告和曲線圖，然后通過Email告訴各軟件負責人，下一步應該注意哪些問題就可以了。我們國企老總很愕然，百思不得其解。如果沒有相關的軟件研發(fā)流程和指導原則、配套工具以及熟悉這些的員工，管理層無論如何達不到這樣的“輕松自在”--- 用Email進行研發(fā)管理。

       有時候想，我們需要“拿來主義”。與其羨慕Bill Gates的錢袋、痛罵微軟帝國的“霸權”，還不如好好研究學習人家的研發(fā)管理和企業(yè)管理：如何把幾萬個聰明的腦殼有效的管理起來？如何讓分布全球的幾千名研發(fā)人員每隔上18個月生產(chǎn)出新版本的Office和Windows？為什么我們上百人、幾十人甚至幾個人的軟件企業(yè)就管理不好？

孟巖：在整個Bug管理的系統(tǒng)中，測試人員是非常關鍵的一個角色。以前測試人員在團隊里的形象好像是灰色的，這兩年各公司都開始重視測試工作和專業(yè)測試人員的培養(yǎng)。你覺得測試人員在Bug管理體系中處在一個怎樣的位置上？測試人員與開發(fā)人員之間的關系如何？

劉振飛：測試人員在整個軟件研發(fā)管理體系中都是一個十分重要的、無法替換與省略的角色。經(jīng)過多年產(chǎn)品研發(fā)的體會，我現(xiàn)在無法想象一個軟件企業(yè)沒有或者不重視測試和測試人員。就像沒有經(jīng)過質檢人員檢驗過的流水線生產(chǎn)出來的電視機，能出廠嗎？會有人買嗎？

       測試人員和開發(fā)人員是對立統(tǒng)一的關系。說對立，是因為測試人員需要專門挑出開發(fā)人員做出來的功能模塊的毛病、發(fā)現(xiàn)其考慮不周的地方；說統(tǒng)一，這兩個角色需要努力協(xié)同工作，把負責的模塊做好。只有每一個模塊問題減少了，整個產(chǎn)品才能提高質量；好質量才有好價錢；公司賺到錢了大家才能有好收入。所以開發(fā)和測試是同一戰(zhàn)壕里的戰(zhàn)友，只有共同努力才行。

孟巖：現(xiàn)在很多開發(fā)工程方法提倡“全員測試”，很有點類似日本企業(yè)里流行的“全員質量管理”。特別是單元測試已經(jīng)將功能性測試變成開發(fā)人員的一項職責，這是否與Bug管理體系有沖突？全員測試是否會導致責任的不清晰？你覺得單元測試與Bug管理是否矛盾？能否協(xié)同工作？

劉振飛：一點也不矛盾。開發(fā)人員把一個功能模塊送去測試的時候，應該已經(jīng)把最基本、最常用的功能邏輯測試通過，否則測試人員發(fā)現(xiàn)這些基本問題后，很快還得退回去給開發(fā)人員，這樣雙方都費時費神。

       我所理解的“全員測試”就是每個人當發(fā)現(xiàn)問題的時候，不能說“這是測試/研發(fā)人員的事情”而置之不理，而應該把這個問題記錄到Bug管理工具中，或者告訴相關的測試人員去跟蹤。產(chǎn)品是公司的產(chǎn)品，是大家共同的飯碗。當然測試人員的專職工作就是去分模塊測試，而且測試得有計劃、有條理、有總結歸納；別的同事可能不是那么系統(tǒng)化而已。

       在Office 2003（Office 11）發(fā)布后啟動的下一版Office 12研發(fā)伊始，微軟Office組的管理層就根據(jù)大家的反饋，啟動了一項叫做“Engineering Excellence”的活動，全面總結上一版研發(fā)流程中經(jīng)驗教訓，提出了十多條大的、具體的過程改進辦法全面執(zhí)行，其中有一條叫做“Feature Crews”，就是加強測試：在把源代碼check in到代碼庫之前，就開始測試一個功能特征（Feature）。該Feature對應的PM、Dev、Tester緊密合作在本地Build上，當一個Feature進入總產(chǎn)品代碼庫的時候應該經(jīng)過認真測試、非常穩(wěn)定可靠，就是說把測試工作大大往前（開發(fā)階段）提了。當然Office組有專人立即設計、開發(fā)相關的支撐工具去保證“Feature Crews”這個新方法能夠順利執(zhí)行。當我第一次看到這份“Engineering Excellence”活動說明時，真是佩服得五體投地！！很多像這樣具有優(yōu)秀管理、執(zhí)行能力的各個小組織，組成了微軟公司優(yōu)秀的大團隊。

孟巖：這樣吧，假設你領到一個團隊進行軟件開發(fā)，以BugFree為基礎進行Bug管理，能否簡單地介紹一下你打算制定怎樣的Bug管理協(xié)作制度？比如，有哪幾個角色，角色之間如何協(xié)作，那些規(guī)定需要作為硬性要求保證執(zhí)行，如何保證等等。

劉振飛：我現(xiàn)在還真是正在帶領著一個團隊去這么干（北京金環(huán)天朗通信技術發(fā)展有限公司 http://www.）。我所計劃的Bug管理指導原則是：

ü         產(chǎn)品（WAP、彩e或彩信雜志、網(wǎng)站等）中碰到的所有問題都要用BugFree來跟蹤處理

ü         有一個專職的測試小組

ü         團隊中每個同事發(fā)現(xiàn)一個問題時，都有義務去告知相關的人員或者直接創(chuàng)建一個Bug

ü         需求、開發(fā)、測試三個角色的定位要非常明確。特別的，提出需求的人要把需求認真考慮好、細化成文檔，然后才能提交正式開發(fā)、測試

ü         發(fā)現(xiàn)一個Bug時，測試人員提交給某個開發(fā)小組長，他來負責指派給具體的開發(fā)人員；產(chǎn)生爭議的時候由需求定義者來出面說明；“矛盾”很大時我來協(xié)調和仲裁。Bug的處理過程都要用BugFree記錄下來：

ü         每天系統(tǒng)自動通知頭上有Bug的人自己還有幾個問題。我會檢查這些Bug，看到不合適的地方就去添加我的意見

ü         每周系統(tǒng)自動通知所有人前一階段Bug的整體情況；同時測試小組要匯總上周的Bug測試情況，告訴團隊中所有同事哪些模塊容易出問題、主要有哪些類型的問題

上面這些我能夠作為“硬性要求”的，只能是前兩條：

?         任何人再向開發(fā)人員反映問題的時候，開發(fā)人員會告訴他們：創(chuàng)建一個Bug來跟蹤

?         剛剛成了一個測試小組

其余的只能融化在日常工作中，管理層不斷在很多細節(jié)上要求、甚至親自示范（比如我會使用不同的產(chǎn)品，發(fā)現(xiàn)問題上Bug），去教會大家測什么、如何測、發(fā)現(xiàn)問題怎么辦、Bug解決后怎么辦。

因為整個研發(fā)團隊剛招聘了不少新人，由于歷史的原因以前也沒有重視測試工作，大家這方面的經(jīng)驗相對而言比較少，所以目前我最重要的工作是給大家不斷灌輸這些意識，手把手去教他們如何創(chuàng)建一個Bug、解決一個Bug時應該怎么描述、提供哪些信息等等。坦率的講，這個過程會非常辛苦勞累。去年我在的公司比較小，一切我都可以從零開始設計規(guī)劃。但現(xiàn)在不同，因為公司業(yè)務有很多、人員也有了一定規(guī)模、以前的程序有很多，而且基于這個行業(yè)自身的特點，新的需求很多、變化非常頻繁，所以在這種情況下如何把研發(fā)流程理順、Bug管理到位，對我也是很大的挑戰(zhàn)。我會根據(jù)對業(yè)務的深入理解去不斷調整、細化上面提到這些“制度”。

孟巖：BugFree在設計上為此作了什么特別的考慮？

劉振飛：我想主要有這么幾點：

（1）       BugFree是基于Web的Bug管理系統(tǒng)，我們研發(fā)人員很容易上手使用、簡單方便

（2）       一個Bug從創(chuàng)建到關閉這個“生命周期”的處理過程，BugFree 全面借鑒微軟內部工具Raid的處理流程，處理方法甚至一些詞匯都和Raid一樣，代表著“先進的生產(chǎn)力”J

（3）       當一個Bug被指派給你的時候，系統(tǒng)會自動給你發(fā)一封郵件，提示有個Bug需要你處理，這樣結合 Email，不斷提醒研發(fā)隊伍Bug的存在和進展。我們還增加了兩個Bug統(tǒng)計功能：一是每天定時（比如早上8點鐘）每個同事都會收到一封Email，告訴他/她頭上還有多少 Bug等待處理；二是每周一中午給所有人發(fā)一封郵件，告知上周Bug的處理情況和到目前為止所有Bug的統(tǒng)計數(shù)據(jù)

（4）       很方便的去自定義查詢條件，以后輕輕點擊一個按鈕隨時查看你關心的Bug

（5）       BugFree是用開源的PHP+MySQL寫成的，規(guī)模很小、代碼也很規(guī)范，所以需要的時候很容易定制或擴充功能

孟巖：非常感謝你，劉振飛。我們通過這三期訪談，已經(jīng)較全面地談到了Bug管理的方方面面。從前兩次的反應來看，很多讀者都對這個話題非常感興趣，你能否用三句話總結一下你的主要觀點？

劉振飛：

1．  測試是軟件產(chǎn)品研發(fā)的重要一環(huán)，需要IT企業(yè)的高度重視，就像重視開發(fā)一樣

2．  選擇一個得心應手的Bug管理工具，比如使用最接近微軟內部Bug管理系統(tǒng)的開源軟件BugFree ，是免費的！J

3．  明確Bug管理的流程和指導原則，并把這些意識逐步灌輸?shù)矫總€研發(fā)人員頭腦中；同時根據(jù)企業(yè)的具體情況不斷去完善測試流程和方法

也真誠感謝你做這次訪談，通過這么多有啟發(fā)性、很有條理的問題，我算是有機會把這么多年的軟件研發(fā)經(jīng)驗、特別是Bug管理的體會系統(tǒng)的總結一下，給自己留下一份很有意義的記錄。同時借這個機會，也感謝給我Email探討Bug管理實踐以及BugFree系統(tǒng)的讀者朋友表示感謝，如果這三篇訪談能對大家的實際測試管理工作有所幫助、BugFree能夠被真正使用起來，那我就非常自豪和快樂了。

另外，我也會根據(jù)自己的使用經(jīng)驗和網(wǎng)友們的反饋，逐步完善BugFree，讓它成為一個長期的、有生命力的開源項目。

孟巖：最后一個題外話。我知道你現(xiàn)在從事研發(fā)管理工作，招聘過不少技術人員，對那些未走出校門的大學生和剛剛踏入社會的大學生們，有什么意見和建議？

劉振飛：春節(jié)后我剛剛完成我們部門今年的第一輪招聘，一共收到了1000多封簡歷、面談過近100人，最后錄取了9名新同事。去年也曾招聘過一些新人；一方面是很多大學生工作不好找、另一方面是很多企業(yè)招到一個合適的人也很費勁。在招聘過程中，真是什么情況都碰到過。

作為一名有幾年工作經(jīng)驗的老畢業(yè)生，我想對年輕的學弟學妹們提幾點建議以共勉：

1.         爭取做一個善良的人、多站在別人的角度上去考慮問題。

2.         要樹立為自己努力工作的心態(tài)，你不僅僅是為老板打工。如果對工作不滿，趕快換一個，千萬不要耗著；我們比上一代人幸運、可以有更多的選擇工作機會，所以不要浪費自己的青春年華。

3.         珍惜在學校讀書的四年寶貴時光，打好專業(yè)基礎（比如計算機專業(yè)的起碼應該把離散數(shù)學、數(shù)據(jù)結構認真搞明白）、提高基本素質（比如誠信、溝通表達及團隊協(xié)作能力）。

4.         如果你想朝技術方面發(fā)展，多去鉆研鉆研那些優(yōu)秀的開源軟件，學習別人的智慧；

5.         擺脫那種非常純的技術情結，要逐步明白在市場經(jīng)濟的企業(yè)中，業(yè)務、管理最重要，技術是一種“后勤支持”，沒有我們想象的那么重要。

6.         不斷學習來提高綜合素質。技術之外的書籍：哲學、歷史、經(jīng)濟、文學等都需要好好讀一讀。古人云，“世事練達即文章，處處留心皆學問”。比如我看電影和話劇的時候，覺得這兩樣和軟件研發(fā)非常相似，劇本就是需求、演員就是開發(fā)人員、彩排類似測試，導演呢就像一個項目經(jīng)理，一個票房很高的電影就像很受歡迎的軟件產(chǎn)品一樣。

7.         身體是革命的本錢。毛主席他老人家的這句話千真萬確，健康的身體是扛住工作和生活壓力的重要保證。

8.         想辦法去慢慢培養(yǎng)自己金錢和管理意識，碰到合適的機會也可以嘗試自己創(chuàng)業(yè)，即使失敗了也可以學到很多書本之外的知識。難道陳天橋生下來就注定要當中國大富豪嗎？王侯將相，寧有種乎？J

順便提一句：熱烈歡迎感興趣的同仁加入我們公司！我們一起經(jīng)歷這充滿挑戰(zhàn)性的過程！