在工作中經常遇到當產品上線出了bug后，第一個受到指責的是測試人員，”測試為什么當初沒有發現這個問題呢”，這種情況在現實工作中數不勝數，也許他們把測試人員當”超級魔法師”了，經過測試之手的東西就完美無瑕了，這就屬于角色定位問題，當定位好自己的角色后，在協商角色內容時，就有了在可能出現的任何情況下現的問題時首先確立對自己預期的基礎。

一、善于提出問題

測試人員在需求分析或者在測試過程中不問問題，不是不能測試，只是不能更好的測試，問問題是測試人員對項目發揮作用的基礎，不問問題，測試就沒有目標，思路不夠開闊，分析不透徹，只是呆板的機械的測試固有功能，之前聽阿里一位同事講過，他們在發布的任何產品的測試報告中必須體現出項目的風險點是什么，如果不思考不分析，風險點是不容易提出的，那么測試意義就會打折。

二、與開發人員高度配合

為程序員提供支持，才是測試員使命的關鍵部分，當程序員還在編寫代碼或者編寫完成待提測時，必要時測試人員能夠提供測試工具為開發人員快速驗證使用，而在程序交付后，應該馬上啟動測試（當然前期測試準備工作需要充分），盡可能建立最短、最快的反饋環路。力求當程序員還在苦苦思索上個bug如何解決時，測試已經開始尋找更多的程序問題，最理想的狀態是程序員為了修改bug團團轉，是程序員而不是測試人員成為項目的瓶頸，降低項目潛在風險。而且這里可以加一點測試人員的角色，就是對bug定位問題，不能只看問題現象，需要深入問題本質，一層一層扒開它的面目，為開發人員節省時間，縮短bug生命周期。

三、認清重點

測試員不會發現所有的問題，測試員的任務就是找出并報告重要的程序問題。那么假設一下，為了發現程序所有的錯誤，測試員必須檢查所有可能有問題的地方，要在有可能發生的不同條件下觀察這些地方，還需要一種十分可靠的方法，當所有類型的錯誤發生時，你都能夠識別出來，那么如果一個測試人員能做到這些，要么是這個產品特別簡單，要么測試員的想象能力有限。當我們知道并承認自己不能做所有的事之后，測試員必須選擇如何利用自己的有效時間。

經驗總結：迅速找出重要程序問題。

1、首先測試變更的部分，然后回歸老功能，識別新變更帶來的風險；

2、首先測試核心部分，即關鍵和常用功能；

3、首先測試功能，再測試可靠性，考慮各種異常場景；

4、具備判別bug風險等級的能力；

當然這里要求測試人員對產品有絕對的熟悉了解，更快捷的找到問題；

四、測試不能保證質量

測試人員不是質量衛士，測試既不會提高質量，也不會降低質量，質量好不好代碼底子就在那里，質量源于構建產品的人，聽起來很不可思議，但這也是他們要背負的沉重負擔，測試員使命中另一部分就是幫助他們對付真正的負擔。但如果測試員認為自己是項目團隊中唯一關心交付好產品的人，就不能很好的完成這個使命，說明測試員沒有認清自己的角色，測試員的測試和錯誤報告提供了促進質量保證的信息，而最終保證質量的是整個團隊。所以測試員永遠不要做看門人，否則是對整個產品的不負責任。當你扛起整個產品質量的全部責任時，團隊的其他成員可以放松一點，甚至會大大放松，如果問題遺漏沒被發現，其他成員想當然的會來指責你，為什么你沒發現問題呢，并且同時伴隨的還有對你工作量的質疑。

這里再舉個例子，曾經待過一個敏捷團隊，在那里從來沒有上述問題，為什么呢？因為如果線上出問題，首先找到的是相關的開發人員，他要付最大的責任，那么你就奇怪難道測試員就一點干系沒了？非也，測試員有測試團隊自己的考核標準，會從自身找問題，自然也不會輕松罷了。而這種模式的利好在哪里呢？利好在于當開發人員在寫代碼時候，他就會考慮到質量問題，如果出bug即便測試員沒發現，他們也脫不了干系，那么在接下來的測試工作中，開發人員起了很大的推動作用，這樣就整個團隊就達成了一個目標，整個去保證質量。

總結：質量是需要團隊的所有角色參與者一起分擔的。