如何簡單高效地提有價值缺陷？#
1. 什麼情況應該提缺陷 (Issue)/ 問題 / Bug?#
1）功能同需求不符，或是技術問題
2）問題是自己或小組內不能解決，需跨部門溝通或支持
3）暴露出我們流程或管理問題
4）功能需求不符要提，功能有誤要提，功能不符合大眾口味要提。
2. 缺陷 Defect/Bug 六大要素#
1) 標題：#
簡潔描述 bug，bug 在哪裡發生？
發生了什麼問題的概括，突出關鍵字的作用，保證無語法錯誤，很容易用關鍵字搜索，容易指派給下一個人。
2) 重現步驟：#
完整並簡潔描述 bug 重現的每個步驟，
但不需要包括每一個小步驟，保證任何相關成員可以理解這個問題，
保證按描述能重現問題，如有前提條件，用一句話簡潔介紹並相關測試數據。
3) 實際結果：#
描述看到的實際結果，不能用一張截圖代替。
4) 預期結果：#
正確並且標準的結果，與實際結果相關聯。
5) 環境信息：#
系統和瀏覽器（缺陷系統的提單可選），當還有別的環境信息需要補充時，請在預期結果的下方補充。
6) 附件：#
圖片應該用明顯的畫筆標記出問題點，如有必要需要加上簡要說明；
視頻應該在盡量短的時間內操作完成整個問題重現的過程；
日誌應該附上完整的相關日誌，不要帶上大量不相關日誌。
3. 缺陷 Bug 提交注意點#
除了 bug 六大要素之外還需要注意以下幾點
準確填寫 “模塊”、“所屬項目”、“影響版本”、“類型 / 嚴重程度”、“系統 / 瀏覽器”；
“當前指派” 指給開發負責人（不清楚時請測試負責人協助）；
bug 標題中不需要填寫子系統名稱，因為產品模塊中已經選擇；
指派給對接人作第一次分析並 “抄送給” 上級；
編輯 bug 的優先級。希望 20% 缺陷是 1/2 級，bug 有個輕重緩急，可以優選解決大價值問題。
4. 缺陷調査 (10 個 Why）#
（What）這個問題是什麼?有什麼影響?
（Why）為什麼會出現這個問題?什麼場景下會出現這個問題?
（Where）這個問題是在哪個階段發現的?
（Which）缺陷是在哪個階段引入的?
（Why）為什麼會在這個階段引入問題?
（hoW）如何避免引入這個問題?
（Where）應該在哪個階段發現這個問題?
（Why）為什麼沒有在這個階段發現這個問題?
（hoW）如何才能在這個階段發現這個問題?
（hoW）如何改進基於風險測試的過程，提取預估到這樣的產品風險?