在軟件項目中經常會有各種或大或小的Bug，更甚一點出現Error。
首先針對該bug我們需要嘗試如何定位相關的問題，具體可參看：。
當我們定位出來後，又如何清晰無異議的提出Bug呢？是不是經常遇到別人給你說某某地方有個Bug，然後就沒有然後了...你是什麼反應？或者一個功能表面上看起來都是正常的，但他說結果錯了，然後呢，然後也沒然後了，你去看了一下，好像都正常，沒有報錯什麼的，這時候你是什麼反應？以上可能是我們在工作中經常出現的一些場景；
再說說我們作爲QA人員，在提bug的時候經常犯的錯誤：
-
第一種，只說錯誤現象。在沒有明顯的錯誤情況下，報告錯誤而不說正確的結果應該是什麼，沒有應該正確的結果（預期結果）對比，光說錯誤相當於污衊。
-
第二種，描述籠統。
- 第三種，Bug point缺乏上下文。比如說，某個頁面裏的一個功能按鈕有bug，如果直接報告這個功能按鈕，你是一下子反應不過來的，你的系統分爲很多大模塊，然後下面有小模塊，然後下面有很多頁面，這個頁面裏有很多功能按鈕，甚至很多頁面都有相同的按鈕，那麼到底是說哪個頁面的功能按鈕有Bug呢
以上幾種情況會造成一個直接的結果就是：溝通成本太大！
目前我們一般會分爲2種方式處理在測試過程中的問題：
1.針對複雜/特殊數據才能顯示的bug，可以先把數據造出來跟開發直接溝通後再提相關的bug，這樣是爲了方便防止造數據所造成的時間浪費；也方便開發在測試協助的基礎上快速定位bug；
2.針對一般bug跟蹤，我們可以直接將問題記錄到jira上，由開發根據我們的描述自己去復現和定位問題；
那言歸正傳，我們如何提一個有效的JIRA bug呢？我們主要歸結關注爲以下重要字段：
BUG標題：
要能簡要說明問題
BUG重要性：https://blog.csdn.net/sunshine_mei/article/details/49230199
重要性分類參考如下：
BUG分類：
功能，需求，安全，性能，環境……
影響版本/解決版本：方便關聯看板
影響版本：該bug是由哪個版本引起的
解決版本：該bug是在哪個版本中解決的
報告人/經辦人/驗證人
報告人：提出該bug的人
經辦人：該bug由誰經辦
驗證人：該bug由誰驗證
BUG描述包含如下：
【環境】：儘可能一句話描述讓開發知道你的復現場景
xx測試環境/xx系統/xx瀏覽器等
【重現步驟】：儘可能根據描述用戶可復現（舉例如下）
1）進入測試環境社招後臺
2）進入COE-招聘費用。
3）針對費用狀態爲“已確認”的候選人，點擊【退回】。
4）輸入退回理由後，點擊確定
實際結果：該候選人狀態未更新
預期結果：該候選人狀態變更爲【已退回】
【附件】：可貼上日誌或者可復現文件或者其他的有效信