由于
測試和開發各自所站角度的不同導致了，大家對同一個問題看法的不同，繼而導致做法上存在各自的差異，有的時候會因為一個或者兩個有爭議的問題吵得不可開交，其實都是沒有必要的。
在現實的
工作中卻是會存在的，如果真的遇到了這些問題，在流程正規的公司里解決起來是比較容易的，在流程混亂的公司里則比較難辦。區別在于：一旦遇到了有爭議的地方，通常的做法都是選擇將相關有爭議的人員召集起來大家一起開個會，然后各種闡述自己的主張，這時候大家通常會在會議上商量一個解決爭議問題的機制。例如，開發將問題轉交給需求設計人員，讓其進行判斷到底是采取開發的意見還是測試的意見，這里的話，有個不容忽視的點，那就是成本的控制。
縱然測試提出的意見很具有前瞻性和從產品設計的角度來說，能夠提高產品總的競爭力，由于系統上線的時間，和開發處理問題等進度各方面的綜合考慮，可能測試的意見也會在當前的版本內不予考慮，或許會加入到下一個版本考慮范疇內，從這點來說，測試提出的意見是有價值的；還有可能會出現需求設計人員的誤判，本身是一個很好的提議，由于需求設計人員沒有意識到自己設計出的需求文檔方面的漏洞而斷然去拒絕一個好的提議，在這種時候，作為測試人員自身的素質是否達標就能夠充分體現出來了，有的測試人員之間就不在堅持自己的主張，感覺反正是需求人員設計的，他們說好就是好，說不好就是不好，完全沒有自己任何的思想，而那些素質過硬的測試人員，他們會進一步去思考，他們提出的方案是否值得他們去堅持，如果要堅持自己的主張，那么堅持的依據是什么，要是放棄自己的主張，放棄的依據又在哪里？當發現是需求設計人員的錯誤時，這時素質過硬的測試人員會采取更加巧妙的方式和方法去和需求設計人員溝通和交流，溝通和交流看似好像就是和對方闡述一下自己的觀點，實際上難度卻比較大，當我們去贊同別人的時候，會很快拉進我們和對方的親近感，反之去否定對方的時候，卻很容易拉大和對方的代溝，導致無法說服對方，達成共識！后續的合作可能會因不斷積累的代溝，導致產生不同程度的芥蒂，造成事情處理起來不是那樣的順暢。
流程混亂的公司會出現的問題就是開發和測試可能會相互的指責，開發感覺測試玩命的測他系統，會想著讓測試按照他們的操作手法來使用系統，而測試人員這時也覺得很委屈，如果說只能按照開發人員設計出來的方法使用系統，那還不如讓開發自測系統算了，還要測試干嘛，不是無形中浪費公司測試資源嗎！特別對于一些找出的開發無法修復的問題，態度不好的開發，很有可能會和測試人員吵起來，其實可能很多人會疑問，那為什么不去制定相應的流程進行規范這些事情？流程的制定是一件很簡單的事情，難的是如何讓流程能夠走下去，之所以混亂是由于缺乏將流程貫徹到底的決心和腳踏實地的執行力，如果你此刻身處這種流程混亂的環境里，那么恭喜你，這正好是能夠磨練你盡快成長的訓練基地，會讓你在無形中思考問題不得不去全面，流程如果過于混亂，一般產品的質量基本都是沒有什么保障的，要求做完測試人員要把系統所以可能的風險在測試的時候都得注意到，只要這樣，才能避免上線后出的問題不是由于測試人員的漏測導致的，而是源于其他問題引起的。
當你不斷的在工作中，遇到有爭議的問題首先想到的都是去找相應的依據支持自己的觀點或者否定掉自己的觀點后，你所提的建議就會更具有價值，你自身的素質也就會不斷的得以提高！