領導希望由測試組來澄清需求，很迷茫

修改了一下標題。原本覺得領導就是想撤掉測試組，把整組轉崗成產品經理。最近跟領導溝通了一下，領導表明自己不是讓測試組寫需求文件，是覺得不需要需求文件，測試直接輸出測試用例可以取代需求文件，他覺得這樣是方便測試組的工作……（問到原型圖怎麼辦的時候，領導完全沒考慮過開發測試還需要原型圖這種東西，說他再跟需求組的領導溝通一下）。

有很多前輩給了自己看法，感覺也很有道理。總結起來就是：如果有興趣做產品經理的話，這是一個很好的轉崗機會；但是公司流程混亂，如果想繼續走測試路線的話，可以考慮重新找家流程正常的公司。

———————————————————————————————————————————

大家好，入職一年多了，在社群裡看了很多大佬的經驗分享，收穫良多。這是我第一次發帖，主要是一個入職一年的新人面對團隊變化一些迷茫吧，想找個地方傾訴一下，也順便聽聽大家的想法。

我去年畢業之後就入職了現在的公司做測試工程師。IT 團隊說是自研，其實就是給政府和企業客戶做外包。測試組的工作主要以手工功能測試為主，偶爾有專案客戶要求出具效能報告時，會做一點單介面的效能測試；功能測試基本上不接觸資料庫，直接看頁面表現；完全沒有涉及自動化測試，因為專案的性質，也很難進行自動化測試。一般一個專案由一個測試人員獨立負責，一個測試人員負責多個專案。

團隊內部的工作流程比較混亂，需求組需要做售前、需求文件、專案管理等多種職責的工作；導致經常是一句話需求，需求評審會也只是需求簡單念需求文件。測試組在團隊中的存在感比較低，經常是需求組和開發直接溝通，等到開發完成了直接通知測試人員進行測試。在實際的測試過程中也發現很多缺陷源於前期需求不明確和開發人員對需求的誤解導致，經常會出現 “A 模組的資料需要在 B 模組展示，A 模組進行刪除操作後導致 B 模組展示異常” 這類問題發生。因此測試組有向領導反饋過這種情況測試工作很難展開。

領導最近提出的解決方案是：既然測試覺得需求組的需求不明確，那就由測試組做需求。需求組負責售前，簽了合同之後需求和互動全部由測試組跟客戶確認敲定。至於專案內部是寫需求文件還是測試人員和開發口頭溝通，不管；反正敏捷開發就是不重視文件的。目前團隊內已經在著手找專案試行這個制度了。

可能是科班出身把有點技術崇拜吧。雖然測試組內部一直覺得測試不需要懂技術，但是我覺得測試工程師即使是功能測試也應該清楚專案在技術上是怎麼實現的，才能發現潛在的問題和風險。也有在學習效能測試、自動化測試，包括孫高飛老師的大資料測試、AI 測試的相關知識；我希望提高自己的測試水平，成為一個更有能力的測試人員；也在努力探索適合測試組的提升方式，提出過一些為了幫助團隊提升專案質量測試組也許可以做的建議。

但是領導現在的方案給我感覺，團隊根本不需要專職的測試工程師，他們需要的是會功能測試的產品經理。現在這樣不就是需求組做專案經理的角色，測試組做產品經理的角色嘛。其實可能領導也沒有錯吧，這確實是解決團隊現在問題比較好的一個方案，只是和我的職業規劃和定位背道而馳罷了。

因為這件事，最近也在考慮要不要乾脆跳槽換家公司做測試。但是家裡人很反對，覺得現在經濟形式不太好，現在的公司穩定工資又還不錯，幹什麼不是幹；又有點覺得家裡人說得很對。總之就是很迷茫吧，不太確定自己未來的發展方向了。