在我的公司，這些規則適用於：Bug跟蹤的最佳實踐
？它適合你嗎？
我們使用的Bugzilla的bug跟蹤和有類似規定：
任何人都可以報告bug和每一個小變化任何應通過bug跟蹤系統。如果是產品增強功能，則應該將該錯誤標記爲增強，並應遵循錯誤跟蹤系統。
任何人都可以分配給其他人，這意味着有緩解，如果錯誤存在於別人的代碼路由的問題，以他人的錯誤。在某些情況下，需要修復多個位置的錯誤，即先依賴別人的代碼先修復，然後再修改其代碼。在這些情況下，首先將錯誤分配給需要先完成工作的人員，然後通過重新分配將錯誤重新分配給合適的人員。
如果一個問題出現在多個地方，並且背後的代碼不同，但問題顯然是相同的，則會克隆該bug，以便可以保留所有更改的單獨跟蹤。
技術主管負責優先基於特定方位的需求的錯誤。
測試儀/ QAEs負責指定嚴重性的錯誤，即關鍵/主要/次要等
所有的錯誤都要經過bug跟蹤系統。來自客戶的錯誤通過自定義標誌單獨分類以指示客戶錯誤。客戶錯誤主要在較早發佈的版本中，並且補丁是爲它們創建的，因此這些錯誤是分開的。
這樣，我們必須確保我們保持所有的在我們的源代碼控制系統（這是TFS的BTW）和Bugzilla的同時改變軌道，使任何變化可以追溯到原始代碼變更/所有者如果將來需要的話。
等待，你寫的：
如果開發人員的問題是由 阻止其他開發人員的代碼，她必須 解決的bug 跟蹤系統之外的這個問題。
所以有錯誤超出了正常的錯誤流程。那麼你有第二個跟蹤這些錯誤的系統，還是這些都是臨時的？
聽起來像是你的bug跟蹤系統是一個真正的用戶缺陷跟蹤系統。
它是否滿足您的需要或您是在尋找替代品？
它對我認爲的管理工作很好（當然不適合我，但這不是我可以改變的事情）。你談論的第二個系統大多是電子郵件。 – 2009-01-21 12:20:09
當他們應該關注的東西完全看不見時，它對管理如何運作？ – 2009-01-21 18:55:36
我認爲客戶也應該能夠創建問題，而bug報告和功能請求之間沒有分離。
問題的分配不應由開發人員自己執行：決定下一個版本需要解決哪些問題應該由客戶和經理負責。
其他做法可以在Joel Spolsky的Painless Bug Tracking中找到。
聽起來很複雜。我們大致採用以下流程：
這是一個輕量級的過程，鼓勵開發人員爲他們的問題負責。
除此之外，無論變更請求的來源和類型如何，我們都有一些適用於更改軟件中任何內容的過程的質量保證措施。其中特別包括：
在過去的10年中，我使用了幾種不同類型的錯誤跟蹤系統，包括沒有任何內容，Word文檔，FogBugz，Bugzilla和Remedy。 FogBugz是迄今爲止最好的一個。在這項工作中，任何人都被允許輸入錯誤，任何人都可以爲其他人分配錯誤。我發現這很有效，特別是如果我在代碼中發現了一個小錯誤。與其花費一個小時寫電子郵件和填寫表格並讓其他幾個人參與，我可以很快記錄下我找到的並修復了一個錯誤。這鼓勵我輸入所有我發現的錯誤並迅速修復它們。如果一個bug需要很多工作，那麼我會把它分配給我的經理，以便他可以將我的其他工作放在優先位置。
在我使用Bugzilla的工作中，每次創建，分配或更改錯誤時，都會向所有開發人員和管理人員發送電子郵件。這有相反的效果，它阻止我發現並輸入系統中的錯誤。
我的小商店採用了非常簡單的工作流程：
這樣，所有東西都被記錄在bug跟蹤系統中，我們通過不限制更新來保持高效。這種方式最終會帶來一些「錯誤垃圾郵件」，但這比根據我的經驗創建瓶頸要好。
我們使用JIRA作爲我們的錯誤跟蹤器 - 可以在JIRA中設置各種自定義工作流程以強制執行您的特定流程，但我從來沒有發現在小型組織中需要這樣做。
記錄錯誤是關於速度 - 調查/複製錯誤
對於Web項目所需要的信息只是最低量，這可以歸結爲：1）一個描述錯誤的標題，2）所在的頁面錯誤發生，3）的問題+的屏幕截圖OR一步一步用於複製問題（如果屏幕截圖心不是提供）
截圖說明適用於兩原因非常強大的描述：1）一圖片說千言萬語，2）它給了錯誤報告的可信度（曾經調查過你不能複製的錯誤吃了覺得「看起來像客戶端又做東西了」）
我有一個博客文章，其進入主題的更多：Logging Bugs Like a Pro
我已經使用了大量的問題跟蹤系統，包括gnats（唉！），Bugzilla（略少），Trac，Jira和現在的FogBugz。我最喜歡Trac，但這可能是因爲我不是FogBugz的管理員，而且在目前的版本中，它被傷心地和可怕地錯誤使用。
讓工作流程正確非常重要，而且奇怪的是，它首先決定在bug追蹤器中放置什麼以及如何標記放置在那裏的東西。只要你有一個客戶，所有的開發團隊真的追蹤三種問題：
真實客戶（活錯誤）指出的問題。
目前正在開發的新軟件（dev bugs）出現問題。
我們想要在未來做的事情（功能）。
當然，這三類問題都有各自的優先級。只是按鈕上拼寫錯誤的「活動錯誤」可能不如阻止公開發布的「開發錯誤」，或者對其他開發，測試等進行門控。
問題的嚴重程度描述了副作用有多可怕。根據我的經驗，這可歸結爲：
程序正在破壞一些東西。數據，客戶被錯誤地計費，錯誤的藥物被分配。這是一樣糟糕的。我曾經在一個系統中工作，在這個系統中，一個軟件指令通過一名維修人員撤回了一個液壓臂。這是一樣糟糕的。
該程序正在崩潰，我們沒有解決方法，但在此期間它不會破壞任何東西（除了被關閉以外）。如果停機時間在某些情況下被破壞，請使用嚴重性＃1。
該程序行爲異常，但我們有一個可以實際使用的識別變通辦法。
該方案是行爲異常的方式，很煩人，但不影響結果。
程序需要在一些明確的方式更好：更易於使用，實現了新的功能，運行速度更快，等
是出現了很多在這些系統中的另一個問題是概念'角色'。應用於問題追蹤系統時，角色歸結爲允許誰做事。誰會創造問題？誰可以改變狀態，誰可以將他們重新分配給另一個用戶，誰可以關閉他們等。
在我與之密切合作的中小型團隊中，這套一般規則集運作良好：
任何人都可以創建問題。創建者可以在創建時將問題分配給任何（或大部分）收件人。默認收件人是Issue Triage團隊。開發人員可以通過這種方式記錄他們在代碼中發現的錯誤，並將錯誤分配給他們自己，以便跟蹤他們改變代碼的原因。
Triage團隊滿足（指定間隔）以評估和分配問題。 Triage團隊專門查找重複報告，在這種情況下，新問題被「彙總」到現有問題鏈中;來自該領域的未再生問題，這些問題被分配到QA進行再生產;以及來自客戶的高嚴重性問題。
錯誤的發起者是唯一可以關閉它的人。 QA或CSR發起的錯誤報告不能由開發人員關閉。是的，這意味着CS和開發團隊不同意的錯誤仍未得到解決。當人們不同意時，爲什麼問題跟蹤報告問題會得到解決？如果你想要謊言的數字存儲庫，你有C-SPAN。
有些球隊可能要預訂一張從一個部門移動的問題到另一個經理，其他球隊可以允許任何團隊成員在移動的問題（或返回到）另一支球隊。這可能歸結爲管理層的懷疑，或者簡單地歸結爲誰可以分配工作時間。
分類過程是關鍵。 Triage團隊基本上是由你的組織決定哪些人在做什麼以及接下來做什麼的人。讓團隊定期舉行會議有助於確保真正重要的東西不會被錯過，並且平凡的東西不會由於不注意而被放棄。如果Triage隊列中沒有任何內容，會議領導可以取消會議（concall，netmeeting，無論實施是什麼）。
如果您使用的是Scrum，Triage團隊可能是scrum的主人，決定是否將問題拉入當前衝刺階段，並在進入積壓時正確指定優先級。
你使用的是什麼錯誤跟蹤流程？
它對我來說很理想。你還可以指定管理層如何跟蹤誰在做什麼，他們如何確保每個人都負責任地工作，並且不只是通過告訴「不是我的錯」來指定另一個開發人員來避免責任？ – 2009-01-21 12:27:09
團隊領導跟蹤團隊內部發生的一切事情。所以，如果任何錯誤被錯誤地分配，它很快就會被捕獲。 BugZilla有一些非常好的搜索機制，通過它你可以跟蹤大部分的事情，比如誰在做什麼，重新開啓了多少bug等 – Aamir 2009-01-21 12:32:34
+1，因爲它似乎遵循我們所做的。 – Klelky 2009-01-21 12:50:15