這個問題似乎不難回答，只要測試部門發現的問題，都叫做BUG。但是，這個問題還可以再追問一下，那麼測試部門憑什麼認定這是一個BUG呢？
這個問題似乎也不難回答。比如：死機、崩潰、跳轉錯誤，提示語不對，錯別字等等……，這些東西，明顯都是BUG呀。
以上這些BUG都是顯而易見的，比較容易達成共識。但是，還有更復雜的一類BUG。
註冊新賬號的功能，註冊完成以後，應該怎麼辦呢？是直接自動登錄，還是返回到登陸頁面，不厭其煩地再讓用戶登錄一遍？
登陸以後，如果5分鐘之內沒有任何操作，要不要自動退出？
這兩個問題，看似簡單，其實涉及到了安全性的問題。
如果註冊賬號以後，就可以自動登錄，雖然方便，但是不太安全；
如果登陸以後，不論多久不進行操作，都不自動退出，更不安全；
從安全的角度上考慮，當然是要再次登錄和自動退出才對。
可是，測試人員不這樣認為。因為，對於測試人員來說：
與需求文檔不符的，都算是BUG。
哪怕程序員認為需求不合理，然後自作主張地改成了更加合理的方式，仍然是BUG。這就是測試部門的原則。
有人會問，那麼如果是產品經理設計得不合理，或者在需求文檔裡沒有說清楚，應該怎麼辦呢？
那就是產品經理的責任了。
所以，在評估BUG時，產品經理一定要在場，就是這樣的道理。
你是產品經理，你來說，當初寫需求的時候，你到底是怎麼想的？
產品經理的一句話，就決定了一個問題到底是不是BUG。
從這個角度上說，產品經理的需求文檔PRD，是一個重要的物證。
因為，你白紙黑字寫得清清楚楚，大家都是按照你的需求做的。證據確鑿，不可抵賴。從始至終，你必須要對自己的文檔負責任。
所以說，作為產品經理，寫需求文檔的時候，一定要慎之又慎呀。
分享到:
閱讀更多 星河系教育 的文章
