【UI型Bug定義】
這里指的UI型指以下兩種Bug：
第一種是文字型Bug，即和給定的字符資源不一致的Bug，比如文字/字符/提示語/引導語/用戶協議等文字方面的不一致。
第二種是UI效果不一致的Bug，比如應該是個圓角按鈕，做出來的界面卻是個平角的按鈕；有下拉箭頭效果，做出來的界面卻沒有下拉箭頭效果；混動界面應該有3屏，做出來的界面卻只有2屏，諸如此類。
【UI型Bug的產生】
理論上UI型Bug的產生只有一種原因，即開發人員沒有按照需求文檔或者UI做。
開發人員為什么沒按需求的要求去實現？通常有兩種原因：
第一種，開發人員一開始就沒按需求實現；
第二種，需求方頻繁變更，沒來得及更新文檔。
在敏捷Agile場景下，開發人員會把最主要的原因歸為需求方沒有及時更新文檔。
【如何減少UI型Bug】
理想情況下，所有的環節都按文檔做，是不存在所謂的UI型Bug的。即需求方確定文檔，開發人員嚴格按照文檔實現。
UI文檔的變動要及時更新并通知到開發人員和測試人員。
開發人員要嚴格按照文檔的需求去開發，不能主動發揮（任何的主動發揮都要征得需求方的同意并通知到下一個環節（即測試環節）的人員）。
【QA人員碰到很多的UI型Bug該怎么辦？】
當UI型Bug占到Bug總數的一定數量后，QA人員有義務想產品或者項目經理提出抗議，說明這是在浪費大家的時間。
【AgileHei測試是怎么做的？】
測試人員不負責測試UI型Bug，由需求方在驗收時統一對UI進行驗收（或者在項目中期約定一個時間進行修改）。UI型Bug是很直觀的Bug，由需求方和實現方直接達成協議，結對及時修改最有效率。
【結論】
UI型Bug是溝通不一致的產物，測試人員不要把有限的精力放在UI型Bug上面。為追求所謂的敏捷而導致了后續環節的頻繁溝通，不是Agile的本意，是為了敏捷而敏捷，為了增加溝通而溝通。