問：你會提交bug么？

答：測試人員必備技能，必然會。

如上對話的起因是這樣的，近日提交bug后 ，開發在jira上備注，你提交的問題什么意思？

當看到什么意思時，有一種被質問的感覺，講真，很不爽，說解決方法之前簡單介紹下實際提交的 bug。

其實提交的 bug只寫了標題（一句話描述了問題以及現象，個人認為這樣就夠了）外加一個附件。（現在來看個人自己給自己挖的坑）

解決方法：

開發看不懂，那就演示給開發看，優先保證開發解決問題。

其次在jira上把問題現象以及操作步驟補充完整，涉及到附件在描述中提及

反思：為何提交的 bug會被質疑？邏輯不清晰？描述不清楚？

問：對測試業務是否清楚？

答：內容不清楚時，找原始材料（需求文檔、測試文檔），問對應模塊產品、開發、測試負責人

問：對測試端是否熟悉？

答：不熟悉時向對應端的測試專家請教

問：對涉及到的輔助測試系統是否熟悉？

答：找相關人員咨詢（測試負責人、負責開發此系統的開發者、產品）

問：提交的 bug是否用開發看的懂的術語描述？

答：盡量使用術語，當不知如何描述時問開發、測試同事、Google獲取對應的術語

問：提交的bug是否按照所在組內的bug格式提交？

答：一定要用組內的格式，入鄉隨俗

問：合作的開發是否喜歡看附件？

答：不是每個開發都看附件的，要在描述中進行提示

其實根本原因在于最近被安排測試app側的內容，然初次下手測，前兩天暈暈乎乎，部分術語與pc端不一致，還涉及到H5、native等，順了兩天才找到節奏，然通過提交bug這事，有些時候還是不能想當然。

最后說下，提交bug的關鍵字段：

1、測試環境（一定要說清楚，尤其有多套測試環境的時候）

2、是否需要登錄（需要登錄一定要提供用戶名、密碼）

3、操作步驟，一句話描述一個動作

4、預期結果，涉及到附件要說明

5、實際結果，涉及到附件要說明

友情提示：

附件中最好有，例如 log日志，關鍵操作步驟截圖，數據庫截圖，配置項截圖，根據bug所需提供即可。截圖在回歸時要比看文字更快速，畢竟自己提交的bug，問題原因已知曉。

提交bug的質量好與壞，也側面反映一名測試的能力，個人認為開發對測試的態度與提交的 bug質量有關，如果你提交的 bug質量不高，需要二次溝通，開發沒意見那是不可能的，所以不要小瞧提交bug這事。