開發認爲不是bug，你該如何處理？

一、需求不肯定
能夠找來產品經理進行確認需不須要改動，三方商量肯定好後再看要不要改。
二、這種狀況不可能發生，因此不須要修改
這個時候，我能夠先儘量的說出是BUG的依據是什麼？若是被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你不少理由，你能夠對他的解釋進行反駁。若是仍是不行，那我能夠把這個問題提出來，跟開發經理和測試經理進行確認，若是要修改就改，若是不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，若是開發人員不修改也沒有大問題。若是肯定是bug的話，必定要堅持本身的立場，讓問題獲得最後的確認。
其實參考答案已經很完整了，可是能夠看到上面的答案明顯是偏向測試人員的，但有時開發說的並沒錯，測試要站在對方的角度換位思考。因此回答這個問題還能夠從開發人員的角度延伸。
（小編只是搬運工，加入了一些本身的經驗實踐在裏面）
分析什麼Bug會讓開發認爲不是bug
一、測試人員描述不清晰
工做中也有測試人員把某些「Bug操做步驟」描述的只有本身看得懂，開發人員按照步驟復現Bug不知所云，搞錯了問題所在。
解決方法：
修改Bug操做步驟：清晰描述、無歧義、無冗餘步驟，要達到即便給一個不懂的人去重現這個Bug，也能按照你的操做步驟復現。
（重要的是：有圖有真相，帶有清晰說明的截圖比一大推描述來得直觀，易懂。注意對問題區域以強調色（如紅色）標識，並配以名字說明）
二、難以復現的Bug
不是全部的問題都能用一樣的操做步驟來複現的，有的Bug機率出現甚至偶現，或者是隻在測試環境裏出現。
解決辦法：
針對難以復現的Bug，須要保存截圖或者記錄log保留證據；對於只在測試環境下才會出現的，找研發在測試環境進行確認。這類Bug要慎重對待，規避風險。
三、有爭議的Bug
有爭議的Bug多發生於建議類型的Bug：與同類軟件不符、易用性、美觀性等類型的Bug。
解決辦法：
這種問題是否要修改須要根據公司的項目類型進行討論。開Bug評審會，在開發能實現的狀況下說出本身的理由，改善產品。
（在時間容許的狀況下，在項目測試接近收尾時開一個bug清除會議，對於剩餘bug是否修復作明確處理）
四、功能性Bug
與需求不符、與原型設計不符。有時候開發對需求沒有深刻了解可能會忽略或者搞錯個別功能。
解決辦法：
拿證據（需求、設計說明書）給他看，這種bug天然合情合理。（最好在提bug時，就把需求、設計截圖帶上，天然省去了大多爭議，除非開發確實以爲設計有問題，須要從新進行討論設計的）