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