按照我的理解，測試人員對自己的定位，對測試工作的認知高度，直接決定了自己能到達的水平。
第乙個層次:找bug軟體開發人員交付給測試之後，測試人員開始針對該軟體版本進行測試驗證，尋找其中的問題。在這個階段，能夠源源不斷找出問題，摸索出自己的測試思路，能夠借助自動化工具進行規模和壓力測試，都可以獲得一定的成就感和能力提公升。
軟體開發人員因為需要用**來實現功能，因此具體實現細節上肯定比測試人員更清楚。那麼就要求測試人員對於整體方案，還有友商實現更加熟悉，方便整合測試和對比測試。有時候翻看之前的問題單，可能會帶來一些思路。
對於測試點的文件化，優點是更換測試人員後，也能根據文件較快上手；缺點是可能會固化測試套路，覆蓋不到的就一直覆蓋不到。總的來說，隨著測試團隊規模的逐漸擴充，文件化是必然的演進步驟，「新鳥」總要接「老鳥」的班。另一方面，一定要將新的測試思路持續更新到文件中。
第二個層次:做qa(quality assurance)將自己負責的模組，作為整個產品的一部分進行驗證。需要熟悉各個模組之間的聯絡，了解客戶一般是如何搭配使用。qa最重要的思想，是樹立「自己就是站在客戶前面最後一道防火牆」的概念，本著對客戶負責，對公司產品形象負責的態度做好測試驗證工作。
這要求測試人員對自己公司的產品非常的熟悉，對容易出問題的地方做到心中有數，有針對性地進行強化測試。
個人感覺最糾結的地方就是產品質量和交付日期哪個更critical。測試的時間長一些，一般來說會驗證的會更加充分。而站在市場人員的角度來看，當然希望能夠更快地交付客戶。那麼誰的意見最終占上風，取決於公司內qa和marketing誰的發言權更大，也跟客戶對交付質量和交付日期哪個更看重有很大關係。
第三個層次:參與產品定義這個看起來是對測試工作的「越界」，但其實是對測試人員能力的更高要求。如果說前面兩項都是對於"現在"(軟體開發人員已經完成的實現)的測試，那麼這裡就要測試人員對於產品「未來」的走向有自己的見解。小到乙個出錯提示該如何修改才能言簡意賅，大到宣告需要新增乙個功能可以對產品體驗帶來較大提公升，都是測試人員可以通過問題單來推動產品演化的。
這對於那些有志於從測試轉向產品經理的同學尤其重要。
談軟體測試人員定位 三年軟體測試總結
因為一直從事web產品的測試，我的觀點並不一定適合所有的型別專案。工作已將近三年了，雖然這三個年頭裡我都在積極的學習著與測試相關的技術 但是能沉澱的東西很少。相信測試同學都有類似的感覺。不要為了測試而測試 前幾天做了乙個測試的ppt 就是講專案中要用到的測試技術，總結了半天其實實際的產品中沒什麼技術...
測試人員的角色定位
剛開始做測試的朋友很多都在做黑盒測試，而黑盒測試往往對 編寫能力要求不是很高，這樣給剛入門的人就造成了乙個測試人員不需要太多知識的誤解。然而，做測試往往需要很廣泛的知識。不僅僅只是專業上的，而且要了解很多開發人員不了解的東西，在乙個系統裡面開發人員可以只了解客戶需求，而我們的測試人員需要了解整個全域...
（八）軟體測試人員的定位
工作已將近三年了，雖然這三個年頭裡我都在積極的學習著軟體開發與軟體測試的相關的技術 但是能沉澱的東西很少。相信都有類似的感覺。不要為了測試而測試 前幾天做乙個測試的ppt，就是講專案中要用到的測試技術，總結了半天其實實際的產品中沒用到什麼技術含量的技能，熟悉需求，並轉化成用例，待專案上線後驗證功能就...