概述
編寫目的
對由本組負責處理的bug進行管理，通過對bug的提交、跟蹤解釋、驗證流程進行規範，提高bug處理效率。
適用範圍
測試團隊以及其他團隊進行的bug提交、跟進與解釋、驗證工作。
bug管理流程
bug提交要求
要求提交bug要求分類準確、描述簡潔、步驟清晰、有例項、複雜問題有據可查（日誌或截圖）。各部門進行審核，以開發人員的角度來審查提交的bug，確認測試人員已將bug描述清楚。具體要求為：
嚴重性
bug等級說明
常見現象1級
無法正常執行，因軟體原因導致系統宕機、資料丟失等，該級別需要程式設計師立即修改；
程式報錯無法進行其他業務的執行，引起無響應或者伺服器直接宕機等；
功能設計與需求嚴重不符；
資料庫發生死鎖、資料丟失、資料通訊錯誤等；
2級主要功能喪失，嚴重影響系統要求或功能的實現，該級別需要程式設計師盡快修改；
程式報錯但能繼續執行；
無法完成功能的正常操作；
資料錯誤；
不符合需求定義範圍；
效能與需求不一致；
3級影響系統正常執行，主要功能出現錯誤，該級別需要程式設計師修改；
非常規操作出現錯誤；
刪除操作未給出提示；
常規操作未給提示；
可編輯區域和唯讀區域沒有區分標誌；
使用者體驗較差，操作不方便，但不影響功能實現；
資料輸入沒有邊界值限定或不合理；
4級操作不合理或者不方便，建議類錯誤，不影響執行工作功能，對軟體的改進意見或建議，該級別問題程式設計師可時間充足時再修改；
易用性問題（未給出提示資訊或提示資訊不統一）；
缺少注釋或注釋表達不清晰；
查詢等操作響應時間過長；
建議類問題；
介面設計不規範，如ui不統
一、文字排列不整齊、出現錯別字、字型不一致等問題；
跟進與解釋
在bug「新建」到「已關閉」期間，盡量使用禪道系統的注釋功能進行溝通。
當bug被以「不必改」、「無法重現」理由關閉，測試人員應仔細閱讀研發人員的注釋內容，再次檢查報告中是否有遺漏和歧義的地方，確認無誤後再進行處理。
bug驗證
響應速度要求
在問題被研發人員設定為「已解決」後，測試人員應在新版本形成後一周內完成驗證或以注釋形式說明情況。
敏捷開發管理流程
敏捷開發經常遇到的問題 解決上述問題的關鍵 scrum研發流程計畫，開發測試驗證 改bug，發布 分別對應jria中計畫板，任務板 圖形板，發布版 計畫 如何控制範圍，如何做好計畫 需求 故事 通過invest原則建立與分解 要維護完整的需求 故事backlog 根據業務優先順序劃分迭代 迭代計畫會...
敏捷開發專案管理流程
前段時間給大家整理了敏捷開發的流程，最近在整理敏捷開發專案的流程和管理制度，其整理的專案管理規程如下，這份規程也不完全算是敏捷專屬的專案管理規程，主要是在結合我們公司實際的情況下編寫出來的，大家在實際嵌入到公司的過程中可以參考下，不能照搬。1.目的 規範網際網路軟體產品開發專案管理過程，指導開展專案...
敏捷開發流程
在動手設計前，第一步需要對市面上的同類競品進行較為深入的分析，提煉出競品的產品框架 各模組的設計特點，通過對比分析，總結出各競品的優缺點，取其精華，取其糟粕，真正做到後來居上。結合之前的競品資料和使用者資料，我們已經可以有的放矢地開始設計產品的大框架 主要任務流程和操作形式。最初的草稿採用多種方案，...