英文原文：Bug statistics are a waste of time

　　五月初在跟敏捷團隊談論缺陷管理技術時，大家情緒有些激動。談論的思想是團隊中可能不需要跟蹤缺陷的工具。看起來這個想法很另類。幸運的是，沒有人很直接的反對這個想法，參加討論的很多人只是說如果不使用這個讓人喜愛的東西，會造成一系列的混亂，并對此持有悲觀的態度。

　　盡管Lisa提供了一些例子來說明這些工具什么時候會有用，我依然會采取更激進的做法：缺陷跟蹤工具僅僅是一種安慰劑，就像希望做出一個更好的軟件時，拋出一個硬幣到噴泉并許下愿望，然后人們會得到一點點溫暖和舒適的感覺。

　　幾個人堅持認為缺陷跟蹤挺重要的，但是他們不能用另外一種更簡單及更高效的方法做這件事。一個大眾性的觀點是：使用缺陷跟蹤工具是一個可重復使用的雷達，讓團隊看到一個缺陷是否重現，不過這一點用自動化測試會更好些。另外一個觀點是跟蹤bug，確保他們被修復。但是情況不是這樣的。跟蹤bug導致他們在數據庫中積累起來直到被忘記。修復一個bug與修復系統菜單中難懂的標識相比，前者會得到更好的解決。有些人聲稱缺陷跟蹤工具幫助他們分派任務和計劃。一個帶著便利貼的看板會更好的解決這個問題。

　　更大或者分散的團隊也許會從計劃管理系統中得到收益，除此之外有很多更高效和不怎么官僚式的計劃管理工具要比缺陷記錄器好不少。一個非常流行的觀點是bug跟蹤方便人們生成有用的報告，好像這是一個有說服力的論據。Bug趨勢也許對流程改變的跟蹤效果很有用，但是你不是真的需要這種形式上的軟件 —— 你可以根據快速察看得到的數據生成趨勢報告。

　　對軟件質量來說，統計所有過去的bug是沒什么用的，相對來說更實際的工作更有用些。但是做bug統計的人很多，并且很容易生成統計報告。 Douglas Hubbard 在《How to Measure Anything: Finding the Value of Intangibles in Business》把這個現象解釋成為衡量倒置(Measurement Inversion) :

衡量一個變量的經濟價值通常與它通常所受到的關注度多少成反比。

　　一個常見的需要bug報告的借口是，管理者們需要知道軟件的質量現狀。由Bug來判斷軟件質量，這跟由濕度判斷好天氣一樣不靠譜。有可能今天不會下雨，但這并不意味著我會喜歡它，除非外面是零下10度。Alan Weiss在《Million Dollar Consulting》這本書里已經解釋的很好了：

質量，我耐心的解讀這個詞，并不是一些管理者眼中的那些，缺陷什么的。但是在消費者的眼中，質量就是有價值的東西。

　　衡量軟件質量的報告很容易生成，但是價值很低，為什么不花一點更多的時間去確定實際的產品質量，然后再做出報告呢？一個有用的報告，再次強調一下，是為了同管理者們一起幫助他們做規劃，他們是要根據這些報告要做哪方面的決定，并且這些決定對他們來說有多大的價值。無論他們最終怎么樣，這才是報告信息的價值。由于來源的不確定性，這些決定和調查可以幫助我們衡量并減少不確定性。

　　不要執著于缺陷跟蹤工具，好像他們是安全毯一樣，在不同的背景下定義什么樣的質量，例如大量的用戶注冊，會話的承載能力，準確的報告數據，衡量并且跟蹤這些和相關風險。然后讓它們形象化！看看那些家伙在Finn.no都做了什么 —— 他們在那些跟他們主題有關的twitter作者們的個人簡介，照片和人們的評論中解釋這些問題。如果客戶是快樂的，存在一些漏洞也是問題不大的。如果客戶抱怨，跟多少bug是無關的。

　　精彩評論：

　　Sue C 在評論中寫道:

　　所以問題是使用統計數據或者是缺陷數據庫本身的問題嗎？

　　我知道你想要衡量東西是，確定是否正在實現自己的目標。換句話說，更明智地衡量跟蹤的問題。否則跟蹤無關的信息是在浪費時間。

　　不管怎樣，我會說bug跟蹤數據庫可以有價值。

　　我曾在一個較大的公司工作，那里有bug數據庫，還曾經在沒有bug數據庫的一個小公司工作過。

　　贊成和不贊成的觀點如下：

　　贊成:

　　1. 缺陷數據庫為CYA服務。如果你的公司是做審查工作的，可以做為一個問題報告的記錄。它仍然記錄了項目結束或者QA驗證問題修復的結果。

　　2. 不容易錯過缺陷，盡管可能有人會提出在做質量保證，我們應該整理這些bug報告不會錯過問題。

　　3. 一個bug數據庫讓查看打開狀態的缺陷記錄更容易些。例如管理者想把打開的缺陷進行分類。如果每個開發者都有他/她自己的bug列表，管理者很難去處理這些打開狀態的缺陷的優先級。雖然你可以讓每個開發人員給管理者發一份報告，但是如果在數據庫中做這件事會更容易些。

　　不贊成:

　　1. 我認為有些時候QA和DEV之間，僅僅是通過缺陷數據庫溝通是效率不高的。通常，發一封郵件或者打印一份報告，然后跟相關的開發人員一起討論問題更容易一些。從我的經驗來說，嚴重依賴缺陷數據庫可能會減少QA和開發人員之間的聯系。在我看來，在QA和開發人員更直接的聯系會有更有效的溝通，并且大家從這個過程中會學到更多。

　　可能的解決方案：除了數據庫，測試人員和開發者之間有一個更直接的討論問題的方法會減少對缺陷數據庫的依賴。

　　2. 我曾經工作過的很多公司都有缺陷數據庫，但是查詢功能很難用。查詢大塊的文本信息被禁用了。因此，我們不能知道是否有其他測試人員已經報告了同樣的缺陷，如果能這樣查詢，會有更好處。

　　Joe Strazzere 說：

　　”有些人聲稱缺陷跟蹤工具幫助他們分派任務和計劃。一個帶著便利貼的看板會更好的解決這個問題。“

　　或許你真的有足夠大的白板和足夠多的便利貼？又或者你有很少的bug要跟蹤？

　　文章的標題是關于“bug 統計”，但是內容卻是關于bug跟蹤工具的。在我的店里兩個東西是不一樣的。在你那里是一樣的嗎？

　　你的觀點“缺陷跟蹤工具是安慰劑”僅僅是在敏捷團隊中應用嗎？或者甚至你認為在非敏捷開發環境中，相對于看板和卡片來跟蹤缺陷，使用任何其他的東西都是在浪費時間？

　　英文鏈接：Gojko Adzic    編譯：伯樂在線 – 李巖