微軟研發方法團隊=軟件 一個偉大的軟件后面都有一個偉大的故事，一個偉大的軟件后面也有一個偉大的方法。 題記 當Windows 2000經過胎死腹中的危機，終于如鳳凰涅般再生時，微軟決定給整個產品組成員拍攝一張合影，以紀念這個歷史時刻的誕生。到了拍攝那一天，微軟人發現，他們只有把攝像師安排在飛機上才能干好這件事兒因為Windows 2000產品組整整有5000人！ “團隊=軟件”，微軟軟件開發管理理論的基礎可以這樣一個恒等式來表達，軟件可以忠實地展現創造它的團隊的一切優點和缺點。軟件業中沒有兩個完全相同的失敗，但最常見的莫過于新版本跟不上對手的腳步，微軟開發模式的精髓之一，便是通過產品組團隊中每個成員對職責的承諾來控制產品的開發過程，保證新產品準時地、經常地被推出。 這正是軟件業最大的金科玉律！ 開發周期四階段 微軟的產品開發遵循一個完整的開發周期，這個產品開發周期被分為四個階段：規劃階段、開發階段、測試階段（也叫穩定化階段）和產品發送/出品階段（參見圖1）。 微軟中國研發中心中文技術部經理李東女士告訴記者，在產品的規劃階段要做三件事：擬定基于客戶數據的目標描述、基于目標描述的規格/特性說明和基于規格說明和特性優先級制定的進度表。規劃階段中最重要的事情是讓整個產品組的成員對共同的目標形成共同的認同。一座偉大建筑的誕生往往只緣于一位偉大建筑師的不朽貢獻，但一個偉大軟件的設計卻需要成百上千人的智力創造。 第二個階段是開發階段，這個階段也叫主要里程碑階段。微軟的任何一個產品組在這個階段都將根據特性將項目劃分成若干個子項目，每一個子項目的完成就對應于一個里程碑。在李東的經驗中，一般微軟中國研發中心會在這個階段把產品劃分成23個里程碑。Milestone1（第一個里程碑，簡寫為M1）內要完成的是核心的特性和功能，或今后需被共享的部件。那些將對產品穩定性形成很大影響的功能，也應該被放到Milestone1。Milestone2可以放比milestone1次要一些、但也是比較重要的特性和功能。Milestone3放的特性和功能對核心特性和功能的依賴性不大，有的甚至可能根據市場的變化重新評估和取舍。總體來說，應根據特性和功能在結構上的重要性來決定它應當被放在M1、M2或M3來做。 在每一個子項目（里程碑）內，進度表應當具體到每一個開發人員，而且進度表中應當加入緩沖時間。在子項目的執行過程中，程序經理（其角色下面詳述）負責協調開發過程并更新規格說明，在開發人員編碼、優化和調試的同時，測試人員進行Bug測試及報告，直到特性穩定化之后，里程碑才達到。開發階段有一個微軟所有的產品組都會用到的重要里程碑：代碼完成（CC：Code Complete）。達到這個里程碑，意味著所有特性的編碼任務全部完成，特性的集成測試通過后，除解決Bug以外，不再有新的代碼進來。代碼完成是明顯的界線，標志著產品可以交付測試。至此開發周期進入第三個階段。 第三個階段是穩定化階段，也叫測試階段，或叫QA階段。測試人員對軟件做各種各樣的測試，其中開發和測試工作是始終并存進行的：測試人員發現Bug，開發人員解Bug，測試人員再檢測這個Bug是不是解了。如果你是一個程序經理，這個時候去看記錄Bug的數據庫，會發現一大堆Bug急劇涌現，隨著一個個Bug被解，Bug量逐漸遞減。當Bug量控制到某一個特定范圍內就可以發Beta版，進行外部測試。這個時期程序經理要跟蹤監督用戶的反饋，開發人員及時解決用戶發現的Bug。Beta測試結束之后，再經過一段時間的測試，就會達到零錯誤版本（ZBR）里程碑，零錯誤版本里程碑的達到，并不意味著沒有Bug或遺漏的功能，而是標志著團隊的成品達到了事先規劃的品質水平，可以向發布候選（RC）里程碑進軍了。值得注意的是，作為RC的產品，應包含出品之前所必須具備的全部文檔資料。發布候選（RC）可能會經歷RC0、RC1、RC2 等（最佳情況是RC0測試之后沒有一點問題，那是最后要發布的那個產品了），但如RC0以后又發現了Bug，并且大家認為這個Bug必須要解，就又出來RC1，Windows 2000就是經過RC3之后才進入產品發送/出品階段的。 產品有了穩定的版本就進入最后的階段產品發送/出品階段。對于研發隊伍來講，十月懷胎、孩子終于出世的那一天就是發送投產（RTMRelease To Manufacture）。RTM之后到用戶真正拿到這個軟件產品之前還要經過我們耳熟能詳的產品發布會（Launch Event），當然，這部分工作已經被微軟的研發機構移交給市場和銷售機構，由產品經理完成相應的產品宣傳策劃，把產品推向市場。 微軟經典團隊角色 微軟的產品組典型的人員角色有幾類（參見圖2）。一類是產品規劃（Product Planner）和產品管理（Product Management）。產品規劃的使命是通過研究，向產品組提供諸如用戶需求、市場導向、競爭對手和產品方向的分析，確保產品滿足客戶的需要；產品管理的使命是確定獲利市場，同客戶溝通產品的價值。這兩個角色相當于對產品的規劃以及產品的銷售。一類是程序經理（或叫程序管理：Program Management），他負責整個產品開發過程的協調，是微軟各產品組中非常重要的一個角色。 開發人員（Development）、測試人員（Testing）、可用性測試員（Usability Testing）之類，在微軟也是一些比較特殊的角色。此外還有：Beta測試人員（Betas），如果這個產品需要漢化的話；本地化項目管理（Localization Project Manager）；用戶教育（User Education）；最后是售后支持（Product Support）,等等。 盡管微軟的產品組角色定位非常清晰，但這些產品組多為橫向組織，由多個部門的成員組成。比如產品管理屬于微軟的銷售機構，而售后支持屬于售后服務機構等等。微軟不同機構和部門之間的協作性極強，這是保證微軟按時完成高質量產品的重要原因之一。 在微軟的產品開發周期中，每一個角色在不同的階段有不同的側重。在規劃階段，作用比較大的是產品規劃和程序經理。開發階段顯然是開發人員的作用比較大，測試人員則在第三個階段“QA階段”很重要，但是程序經理在這兩個階段的作用都很重要。 產品規劃人員對產品影響最大的作用體現在規劃階段。這個階段的產品規劃需做用戶問卷調查，用各種各樣的研究手段來試圖了解用戶的需求，并創建目標描述。這個階段產品管理也收集用戶需求，但他主要調查的是市場走向，他關心的是如何與客戶溝通產品的價值。產品規劃在整個產品開發周期中總是充當一個用戶代言人的角色。產品管理在第一階段和最后階段發揮作用，產品管理必須設法了解新產品的獲利市場所在，并且很好地同客戶溝通產品的價值。 相比于產品規劃和產品管理，程序經理與程序經理之后的角色與產品具體開發過程更直接相關。 特殊角色程序經理 在微軟的產品組中，程序經理的角色很特殊，他是惟一在產品開發周期的前三個階段都顯得非常重要的角色。 程序經理在規劃階段要貫徹和推進目標描述，書寫功能/特性規格說明，創建主要的進度表。規格說明是基于產品規劃所產生的目標描述來具體定義特性的實現步驟，目標描述文檔是基于大量用戶的調查報告和各種研究方法得出的用戶的需求，定位產品的目標。但這只是給出了一個大方向，程序經理必須把這個大方向細化成若干個具體的特性，這些特性不僅要滿足目標功能的要求，而且又必須是程序開發人員能夠理解的語言。比如 Word某一版要支持HTML，產品規劃只定目標，但程序經理就要把這個目標細化成幾個具體的特性。 在第二個階段，程序經理要管理整個開發工作的進度，檢查開發人員的實現是否與規格說明相吻合，而且要使團隊目標集中、齊心協力。如果在開發過程中有什么特性的變化，或者某些功能在設計時很好但在實際開發中出現問題，程序經理便要負責其更新規格說明，還要與產品規劃、測試人員溝通項目的進展狀態，協調開發過程中出現的問題。代碼完成里程碑達到之后即開始大規模的測試，程序經理那時的作用就更大了，他要制定和控制每個Bug的優先級，做取舍決定，發送Beta版并收集用戶反饋，確保產品按時達到發送候選（RC）。 一句話，程序經理的中心任務是保證軟件高質量并按時出品。由于總是要在品質與進度上找到平衡點，程序經理必須精于“引導、驅策、鼓勵、要求”團隊做出最好的軟件和表現出最好的工作效能。 在微軟不同的團隊里，程序經理所做的事情也有一定的差別。有偏技術性的設計功能的程序經理，他們是團隊中的關鍵人物；有一種程序經理被叫做Release Program Manager，他的主要任務是控制開發流程;還有的程序經理會做一些客戶需求調查的工作，定位產品方向。無論如何，程序經理的基本素質首先是要有很好的溝通技巧，具有設身處地為他人著想的本領；其次考慮問題周全，能處理復雜的情況；此外，程序經理要對開發產品所使用的技術很熟悉，對用戶需求的理解力也要非常好。比如在具體的開發過程中，測試人員發現Bug越多越好，但開發人員卻希望Bug越少越好，程序經理要善于協調二者的矛盾；在產品的開發過程中通常會出現人員突然流動的現象，或者硬件環境出了問題，或者外邊競爭對手出現變化，程序經理對這些要反應非常機敏，有能力做出對公司、產品和客戶影響最小的果斷的取舍和決定。 微軟的開發人員無疑是每一個產品組中非常重要的角色。一個頭銜是軟件設計工程師（SDESoft Design Engineer）的開發人員的級別有可能比某一個經理要高很多。在微軟，開發人員根據他本身知識和能力的不同分為不同的級別，頂級的開發人員負責整個軟件的結構設計，中間有負責某一功能類的結構設計師，最底層的開發人員只完成規定的模塊實現。好的結構設計對產品的穩定性、可擴充性非常重要，特別是對一個由多人參與的項目而言更是如此。在產品組中，最厲害的開發人員是整個產品結構的設計師。應該說，微軟每一個產品中都有幾個核心開發人員來控制整個產品的結構，其他開發人員則在他的領導之下共同完成開發工作。 可用性測試的重要 所有用過微軟產品的人會有一種感覺，微軟產品非常易用。如何使產品做到易用？微軟的辦法是通過重視可用性測試（Usability Testing）來實現。可用性測試的使命是通過在產品開發周期的各個階段加入客戶資料和信息來使產品更有用、適用和易用。 在產品開發周期的第一個階段可用性測試就要展開工作，比如，微軟中國研發中心的產品組會把產品的新特性做一個模擬的模型，找用戶來試用，產品組的可用性測試人員便會在試用過程中準備錄音機、攝像頭，把用戶的行為攝下來，說的話錄下來，按的鍵記錄下來，研究他們對產品的反應，以便把產品設計調整到足夠好。 微軟中國研發中心中文處理組有一個產品 “微軟拼音輸入法”，其最早的幫助功能是用鼠標右鍵擊活菜單，這是Windows常用的菜單風格，但是通過前期的可用性測試，李東他們發現中國用戶習慣了用鼠標左鍵，很少用右鍵，這樣用戶很難找到微軟拼音的幫助功能。后來微軟中國研發中心把“幫助”放在顯示特別明顯的地方輸入法狀態條上，這樣，按左鍵就能使用幫助功能。“用戶的需求可能跟你想的不一樣，這就要真正傾聽用戶的呼聲，讓用戶來試用，看用戶的反應，來決定修改你的產品”，李東告訴記者，微軟中國研發中心這樣的例子很多。 在第二個開發階段，當開發人員達到M1，能看到產品的最重要的特性時，可用性測試人員要隨時反饋設計好不好，如果要有個別的改動，則在M2中將M1的某些功能改動加進來。可用性測試人員要理解用戶的工作領域、行為和心理，微軟公司總部有很多做可用性測試的人員是心理學方面的專家。用戶的感受只有通過可用性測試人員分析、理解成對功能的描述，或者對功能的反饋，才能使產品開發人員能夠理解并改進。 里程碑式的開發模式的好處 綜觀微軟對軟件開發周期過程的管理，其精髓的做法一是將大項目劃分成若干個子項目的里程碑式的開發模式；其次，通過對產品組各人員角色對職責的承諾來控制產品的開發過程，以保證產品的進度和質量。 不管是小軟件還是大軟件，里程碑的概念在微軟所有的軟件開發中都會被用到。這也是微軟在軟件開發上摸索多年凝聚所得。國內軟件企業的開發大多是從有一個想法就開始做，不分什么階段，但往往因為軟件功能太多，不同的人負責不同模塊，到產品的最后階段再去集成和測試，大量原來沒有預計到的問題都“冒”了出來，這時再去“動”各個部分，時間肯定要推遲。這種模式將導致兩個問題:一是質量無法控制，二是時間無法控制。 李東認為，在微軟里程碑式的開發模式下，做同樣大的產品，因為按子項目來劃分里程碑，每一個子項目都經過一定的穩定化階段，再進入到第二個子項目的時候，就是基于一個相對穩定的一部分子項目基礎之上的行為，這樣就將風險或錯誤的累加分散和降低。以局部的質量控制來保證整體產品的進一步穩定，能使得質量和進度得以很好的控制。而且，把一個大的項目分散到不同的階段來完成，可以靈活地去增加或減少一些功能，否則，把增加或減少功能集中到最后集成階段，而且是在不穩定的環境下來做，困難可想而知。這就是里程碑式的開發模式優秀之處所在。雖然里程碑的做法在成本上比較高為了協調出大家對里程碑一致的價值觀，為了協調出里程碑的衡量準則，如此等等，團隊必須付出大量時間和精力，承受比較大的痛苦，但這是惟一能夠確保開發成功的方式。 國內軟件企業的開發模式多為“大拿領銜制”，通常公司十多個技術人員中間有一個技術“大拿”，剩下人輔助他，把這個產品的所有代碼寫完，則軟件就算完成了。“大拿領銜制”脫不去小作坊的味道，雖然保證了“技術大拿”的創造性，卻失去了軟件研發過程應有的規范。 軟件企業的創造性和制度要相輔相成。在微軟的所有里程碑中，“代碼完成”里程碑（code complete milestone），是一個重要的分界線。在代碼完成之前，產品組自由發揮創造力，最需要大量的交互和碰撞。代碼完成之后，則需嚴格按照里程碑完成進度。進入測試階段，微軟通常把里程碑分得更細致，比如Beta、零錯誤版本、發布候選、RTM等等。每個里程碑都不是簡單的擺設，而是有嚴格的規定，快到里程碑的時候開發人員不能做沒到里程碑時的修改，“原來一個Bug怎么改都可以，但到里程碑附近的時候，就要求只能改動最重要的Bug”，微軟中國研發中心副總經理徐汕開發Windows 2000時曾與副總裁吵過架，“我們覺得中文版需要這項功能，但當時已經太晚了，大家爭吵了很長時間，最后還是不能改。”為保證軟件按進度完成，靠近里程碑時需要“收斂”，而收斂惟一的方法就是少做事情。過了一個里程碑，產品比以前的質量就要好許多。通過一個一個里程碑來收斂，這個項目不會偏離目標很遠。從代碼完成到RTM是微軟軟件開發周期中非常重要的過程，這個時候已經完成充分發揮智力的時期，而規范成為更重要的要素。（注：本文只給出了微軟團隊工作方式的常規模式，具體的實踐模式可參考微軟Visual C+事業部總監吉姆麥卡錫所著書微軟團隊成功秘訣。） 微軟研發方法(下)Bug“指揮棒” 想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。 題記 項目經理經常犯的錯誤之一，是以為只要雇用軟件工程師就行，其他的人都不必要，或是讓軟件工程師占整個團隊很高的比例。他們也許認為開發人員越多，寫出來的程序也越多，這是錯誤的概念。項目的目的是為了完成軟件，而不是完成更多的程序代碼。在開發團隊中，實際有一些工作是不適宜交給軟件工程師做的。 要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。軟件開發好像是在趕進度，而不是在演奏交響樂：交響樂是和諧有序而優雅的，而軟件開發卻更像是一堆排山倒海、蜂擁而至的工作。交響樂任何兩個音符都不能相互抵觸，整體表現出來的才是一段優美的音樂。在一切都不確定的軟件開發過程中，讓測試人員的“Bug指揮棒”來使大家知道什么時候該表現，知道什么時候該退后一點，正是微軟將軟件開發過程帶向高潮的不二法則！ 測試組不是開發組的助手 似乎沒有誰比微軟更重視測試的力量。在微軟的產品組中，測試組是與產品規劃組、產品管理組、開發組和用戶教育組等并列的隊伍。測試與軟件成本的關系是，發現產品中存在的問題越早，開發費用越低，產品質量越高，軟件發布后維護費用越低。在微軟開發周期的四個階段中，測試的目的在于保證軟件質量，滿足設計的要求和客戶的需求；系統地揭示出不同類型的錯誤，并耗費最少時間和最小工作量；降低軟件的開發成本和維護成本。 軟件開發過程中開發人員很可能因為一些偶發的小事，或某種無關的靈感而不知不覺中偏離了實際的需要，暫時忘記了什么才是產品最該有的功能，把他們拉回原定軌道中的正是測試工程師。測試人員的職責是配合整個項目組保證按照預定的時間表完成達到預定設計目標的產品。測試人員的工作是具有整體性、持續性的軟件開發活動中的一環，而不是偶爾拿出來點綴一下。軟件產品的質量是由用于測試的資源、產品的功能和項目的時間表來決定的，是三者的平衡。對任何的一個產品組來說，無論是主觀，還是客觀上，都要重視測試工程師的存在，這是產品質量的重要保證。 羅馬不是一天建成的。早期的微軟開發隊伍中也沒有設立單獨的測試組。那個時候的微軟幾百個人做幾個項目，通常是程序員寫完程序了，自己測試一下就算完事。后來微軟的項目越來越大，軟件越來越復雜，寫代碼和測試的工作要平行進行，漸漸產生了獨立的測試組。一個重要的數字是，微軟產品組中測試人員和開發人員的比例大約是11。其實，要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。 測試組獨立于開發組之外的好處在于，程序員總是傾向于認為自己設計的代碼足夠好，獨立的測試組可以使測試人員在不帶任何假設的情況下從不同的角度來測試軟件，有利于保證軟件的質量始終得到控制，并使測試資源得到重用和不斷改進。但是，測試組獨立于開發組之外，并不意味著程序員寫完代碼就扔過“墻壁”，等待測試工程師找到所有的bug，當測試人員認為他的工作就是測試程序，而開發人員認為他的工作就是寫程序給測試人員測試時，如果你是項目經理，要小心了！開發人員的優越感會使測試人員感覺自己是被歧視的少數民族，這勢必會影響到軟件的品質。程序人員在寫完代碼、改正問題后必須完成基本的測試，比如代碼的路徑測試、單元測試和問題驗證等。產品質量控制，存在于開發過程的每一個環節中。 有一個笑話，微軟的測試人員工作時間長了，都有挑刺兒的習慣，下了班見了太太做的飯都要評價一番。對微軟來說，那些聰明、細致、認真，有耐心，追求完美的產品，對用戶有負責任的態度，思維方式獨立又開放，既有足夠的技術背景，但又愿意學習新的技術的測試工程師更容易得到“老板”的青睞。 軟件測試的階段性 軟件開發的過程就像是一支隊伍正在急行軍，但跑著跑著這支隊伍就會“散了架”，設立里程碑的作用就仿佛是到了某一個“點”，大家必須要重新整理步伐，實現同步。就測試組的工作模式而言，測試的階段劃分是與項目的進度相對應的。也就是說，測試人員應當與項目組的其他人員始終保持以相同的步伐“跑步”的狀態，與整個項目的每一個里程碑配合，完成相應的測試工作。 把大項目劃分成若干子項目的里程碑式的開發模式是微軟軟件開發管理的精髓做法，如上一期微軟研發方法（上）所述，在微軟的每一個產品開發周期中都有以下幾個重要的里程碑：CC（Code complete:代碼完成）；Beta測試；RC（Release Candidate：候選發布）；RTM（Release To Manufacture:投入生產），測試人員和產品組的其他人員一起，共同達到每一個里程碑。一個完整的測試循環應當包括運行所有的測試用例、Beta標準測試、bug校驗和解所有的bug、隨機測試。好的測試循環能夠保證對軟件質量有一個全面完整的評價，每個里程碑之前至少要有一個完整的測試循環。 在微軟的產品開發周期中，在規劃階段當開發人員在做計劃、編進度，進行功能實現的可行性研究，對計劃的功能進行反饋時，測試人員應當研究規格說明，編寫測試計劃；在第二個階段即開發階段，當開發人員在編寫代碼、測試和調試的同時，測試人員應當開始設計測試用例，開發自動測試工具和程序，熟悉必需的環境、工具、軟件和硬件，不斷地豐富測試用例，直到達到CC（代碼完成）里程碑這個時候的軟件可以進行一次整體測試，用戶界面可能不完美但能夠工作，可能有很多明顯的bug。 進入開發周期的第三階段，測試人員大顯身手，展開大規模的測試，比如系統級整體測試，交互性和深層測試。測試之后，測試人員應當對新增的功能說“不”，直至達到Bate測試里程碑。達到這個里程碑，意味著所有的Beta致命問題已經被修正和關閉，所有計劃的功能都已經在軟件中并能工作，產品穩定，大部分界面還可以，盡管可能只是一部分，但已經有了在線幫助和用戶手冊，即使是發布了也不會引起負面的影響。 Beta測試的目的是確定產品是否能在預計的各種硬件平臺和操作系統中正常運行，雖然Beta測試的反饋意見很有參考價值，但除非存在重大問題，否則不應對功能集再做修改，所有建議和反饋都留在下一版中再考慮納入。Beta測試之后就要向RC和RTM進軍。測試人員要著重測試Beta后的變動。到達RC，意味著軟件質量狀態為沒有活躍的bug（Active bug）；沒有懸而未決的事；已經穩定了一段時間，如一周內很少或沒有變動，或變動很小。如果RC后的測試沒有發現新的需要改的bug，可以達到RTM，隨后查病毒，驗證光盤，檢查內容。 需要注意的是，在整個階段性的軟件測試過程中，質量不僅僅是測試組的責任。一定要防止完全依賴測試組來保證質量的做法，否則結果只能是質量差、進度延遲。采用Zero-Defect策略的好處在于，可以同時保證產品的質量、進度和功能集，盡早發現和修正產品中的bug，始終把產品的狀態和bug數量控制在可以管理的范圍之內，程序員應該修正所有的優先級為一級（P1）的bug才能寫新的代碼。 同時測試組應當開發一些好的測試管理工具，比如測試用例管理工具和bug的管理工具等等。測試工程師應當細化測試子區域，重視測試用例的數量和質量，對bug狀態的變化要反應迅速。要防止僅以bug多少來評價工程師的工作。 bug的發現和管理 在微軟的測試人員看來，那些功能沒有實現或與規格說明不一致的問題是bug；不能工作（死機、沒反應）的部分是bug；不兼容的部分是bug；邊界條件未做處理是bug；界面、消息、提示不夠準確是bug；有時把尚未完成的工作也作為一個bug。微軟把軟件中常見的bug類型歸為以下幾類：功能錯誤；用戶界面錯誤；邊界值相關錯誤；初始化錯誤；計算錯誤；內存相關錯誤；硬件相關錯誤和文檔錯誤。 測試工程師發現bug之后所采取的措施，首先應當是去想法驗證是不是自己的偶然失誤造成bug出現，如不是則應立即建立每一個新的bug記錄，包括具體的再現步驟、環境、屏幕等；盡可能地分析產生bug的原因；設計合適的優先級和嚴重級別，要記住，測試人員的目標不是找出更多的bug，而是改進產品的質量；依據bug的優先級和嚴重級別分派給某一個相應的人，如程序員、項目經理和測試組的負責人等。 一般來說，bug在數據庫中有三種狀態：活躍（Active）、被解（Resolved）、關閉（Closed）。這三個狀態在微軟通常用“紅黃綠”三個顏色來代表。活躍狀態指的是測試人員新建一個bug時的狀態，必須分派給相應的設計人員、開發人員或者是用戶教育人員，表明bug的狀態是等待糾正的。被解狀態指的是設計人員、開發人員或者用戶教育人員修正bug后的狀態，必須重新分派給報告bug的測試人員，表明bug已經得到修正，但等待校驗。關閉狀態指的是測試人員校驗完成并關掉之后的狀態，表明bug已經得到修正，并完成了校驗，但如果同樣的問題再次出現后，還可能重新激活成活躍狀態，則又開始了另一輪的狀態循環。活躍bug數量的變化趨勢是，一般在代碼完成前很少，代碼完成后增長很快，接近Beta測試時會下降，接近RC時奔向零。因此依據每天新建的bug數量與修正的bug數量相比較和處于活躍狀態的bug數量亦可判斷產品質量和里程碑的信號。 永遠有缺憾是所有智力活動的特征。軟件一定有數不清的缺點，問題不是在于判斷這個產品好與不好，而是決定修改哪一部分從而可以使產品比較能被用戶接受或喜愛。微軟把這個判斷并修改的過程稱為“急救術”。在急診室中醫生必須非常迅速地察看患者面臨的所有問題，采取最急迫必要的急救醫療措施，然后再依優先級分別施救。微軟產品組也一樣，他們把bug的嚴重性分為四個級別：導致死機；主要問題，導致嚴重的問題，如某個小功能未實現；小問題，不太嚴重，如提示信息不太準確；微小的問題，如有個別錯別字。把bug的優先級分為四個級別：盡快修正；每