如圖所示，在Bug管理過程中，Bug的發現即代表誕生，而Bug的關閉則代表結束。註意，這與Bug的真實產生與結束是有區別的。壹個Bug顯然在發現之前就已經存在，但這種定義方式，對Bug管理是有效且足夠的。
如果我們壹個人在壹個時間段能夠處理壹個Bug，如上流程是很簡單的，單線程的操作不會遇到什麽問題。但在壹個App項目的測試或者運營階段，我們實際面對的是同壹時間段；多Bug出現，而且由不同職責的多個同事協同解決Bug。
第壹步發現BUG、提交BUG信息。用紙或者電腦記錄問題，通過郵件將信息反饋到技術人員手中。
第二部是根據BUG嚴重等級分類，比如致命：造成系統死機、程序崩潰、死循環、造成系統主要功能無法實現的異常等；產品的關鍵功能和性能不能符合用戶要求。嚴重：重要功能基本實現，但系統不穩定、會導致數據破壞丟失、運行錯誤、操作性錯誤、功能不能實現、功能遺漏、錯誤結果。然後根據BUG的嚴重等級進行分析，進行修復。
第三部對BUG修復後，技術人員把BUG修復信息反饋給提交BUG人。
選擇好的管理工具，可以有效的提高溝通與確認時間成本。我們團隊現在直接在日事清內進行“bug管理”，提bug人員將bug輸入到“收集”狀態，由產品助理集中處理，視bug具體情況將bug拖拽到其他集中狀態。如果拖拽到“確認”，在該bug下添加相應技術人員讓其處理，技術人員會在日事清協作系統內收到通知並且bug同步到其收納箱，方便技術人員集中處理，解決後由技術人員拖拽到“已解決”狀態卡片，大大提高了工作的效率。