開發說這不是BUG，怎麼辦

讀者提問：開發說這不是 BUG，怎麼辦？

阿常回答：那你覺得是 BUG 嗎。

首先，測試要有自己的判斷，不能開發說啥就是啥。

其次，我們來看看 BUG 常見的四種類型：代碼錯誤、界面優化、設計缺陷、需求問題。

一、代碼錯誤

代碼錯誤，即功能錯誤（功能沒有實作）。

如果判斷下來是這類問題，測試可以在需求文檔中找到描述該功能的地方，用記号筆着重劃線标記，再傳給開發看，相信開發立馬就準備修這個 BUG了。

二、界面優化

界面優化問題，即頁面顯示問題（比如錯别字、排版、布局、字型大小等）。

如果判斷下來是這類問題，我們可以找 UED 确認是否需要修改（錯别字不用說，必須要改），UED 會從使用者體驗的角度來判斷是否需要做界面優化，一般如果改動難度不大，開發也是願意修改的。

三、設計缺陷

設計缺陷，即沒有按照需求文檔去實作功能。

如果判斷下來是這類問題，我們可以找産品一起溝通，功能是實作了，但跟原本需求設計不符合，看看産品能不能接受這個結果，這樣的實作業務是不是也能接受。

如果業務可以接受，産品也點頭認可，那這就不作為 BUG；如果業務不能接受，産品明确要求開發必須按照需求文檔來實作，那這就是 BUG，開發必須修改。

四、需求問題

需求問題，即需求設計不合理。

如果判斷下來是這類問題，我們一般不稱之為 BUG，而叫它【需求改進】，這時【需求改進】我們應該提給産品，而不是提給開發。