周一早上項目經(jīng)理在群里你“這周版本必須發(fā)測試時間壓縮兩天你安排一下?！蹦氵€沒回復測試群里已經(jīng)有人私聊你“老大這個版本需求改了三次用例還沒更新完兩天根本跑不完”。你夾在中間。上面要的是“按時交付”下面要的是“別逼太緊”。兩邊都有道理兩邊都不能得罪。這就是測試管理層最典型的日?！悴皇窃诠軠y試你是在管“期望”和“資源”之間的那道縫。這道縫技術能力填補上。你代碼寫得再好也不能讓需求少改一次你自動化再強也不能讓兩天變成四天。真正能讓你活下來的是另外四件事。一、向上管理期望項目經(jīng)理說“壓縮兩天”你不能直接說“不行”。你也不能直接說”好的“然后把壓力原封不動傳給團隊。你要做的是拿出數(shù)據(jù)、把選擇權交回去?！叭绻麎嚎s兩天我建議優(yōu)先跑核心鏈路邊界場景和兼容性測試延到下一輪。但這樣上線后XX場景出問題的概率會上升。你確認一下這個風險能不能接受”這句話的重點不是拒絕而是把風險翻譯成對方能聽懂的預言然后讓他做決定。項目經(jīng)理要的是“按時發(fā)版”不是“測試必須跑完所有用例”。你把風險講清楚他自然會權衡。向上管理的核心不是“聽話”。也不是“頂回去”而是讓上面的人看見真實情況然后和他一起做決策。二、向下爭取空間團隊成員說明“跑不完”你也不能直接說“那就加班”。你要判斷是真的跑不完還是效率問題是需求變更太頻繁還是用例設計不合理是環(huán)境不穩(wěn)定浪費了時間還是任務分配本身就不均衡如果是客觀原因你的職責是替團隊擋住不合理的壓力而不是把壓力原封不動地傳下去。一個只會傳話的管理者團隊不會服你。團隊需要的是當上面壓下來的時候有人能說一句“這個時間確實不夠我去溝通”而不是“上面要求大家克服一下”。三、跨團隊協(xié)調(diào)測試從來不是孤島。開發(fā)延期、產(chǎn)品改需求、運維環(huán)境出問題每一件都會傳導到測試這里。你需要根開發(fā)對齊提測標準跟產(chǎn)品確認需求凍結時間跟運維確認環(huán)境可用性。這些事沒有一件事“技術問題”全是協(xié)作問題。協(xié)作問題的解法通常不是“誰對誰錯”而是“怎么把接口對齊”。比如跟開發(fā)約定提測前必須跑通冒煙冒煙不過測試直接打回。跟產(chǎn)品約定版本上線前三天需求凍結凍結后的變更走緊急流程。接口對齊了扯皮就少了。管理者的價值很大程度上體現(xiàn)在這些“接口”的設計和維護上。四、流程設計為什么團隊總是加班為什么缺陷總是漏到線上為什么每次復盤都在說同樣的問題這些問題的答案通常不在某人身上而在流程里。準入標準有沒有沒有的話提測質(zhì)量全靠開發(fā)自覺。缺陷分級清不清楚不清楚的話開發(fā)和測試會為“這個問題嚴不嚴重”反復扯皮。復盤有沒有閉環(huán)沒有的話同樣的問題會反復出現(xiàn)。這些事管理者該花時間的地方而不是自己去幫團隊跑用例。流程設計的目標是讓團隊少踩坑、少返工、少扯皮。流程設計好了管理者才有時間去做那些“沒人催但很重要”的事。五、管理路線和技術路線沒有高下之分最后說一點管理路線和技術路線沒有高下之分。測試總監(jiān)可能不如架構師薪資高測試經(jīng)理可能不如測開專家稀缺。選擇哪條路取決于你從什么事情里獲得成就感—事“我解決了一個難題”還是“我讓一群人解決了一類難題”。兩者都值得尊重但對應的能力模型完全不同。