測試的工作很大一部分卡在“接口”上。跟開發(fā)對齊提測標(biāo)準(zhǔn)跟產(chǎn)品確認(rèn)需求凍結(jié)時間跟運(yùn)維確認(rèn)環(huán)境可用性。這些事沒有一件是“技術(shù)問題”全是協(xié)作問題。接口沒對齊測試就永遠(yuǎn)在救火。這篇文章講三個方向的對齊開發(fā)、產(chǎn)品、運(yùn)維。一、跟開發(fā)對齊提測標(biāo)準(zhǔn)和缺陷流轉(zhuǎn)核心接口就兩個提測準(zhǔn)入缺陷分級。提測準(zhǔn)入開發(fā)提測前必須跑通冒煙主流程能走通。冒煙不過測試直接打回。這個規(guī)則一旦定下來雙方都省事—開發(fā)知道提測前該做什么測試不用反復(fù)幫開發(fā)定位低級問題。缺陷分級至少區(qū)分“阻塞”“嚴(yán)重”“一般”三級明確什么級別必須當(dāng)天修、什么級別可以排期。規(guī)則清晰了就不會為“這個問題嚴(yán)不嚴(yán)重”反復(fù)扯皮。開發(fā)覺得“這個問題不大”測試覺得“這個問題很嚴(yán)重”來回爭論的成本比修bug本身還高。關(guān)鍵動作把規(guī)則寫下來雙方確認(rèn)每次打回都對照規(guī)則說。不要靠口頭約定口頭約定撐不過兩周。二、跟產(chǎn)品對齊需求凍結(jié)和變更流程核心接口需求凍結(jié)時間變更處理流程。需求凍結(jié)版本上線前X天需求凍結(jié)。凍結(jié)后的變更走緊急流程需要產(chǎn)品、開發(fā)、測試三方確認(rèn)影響范圍。沒有凍結(jié)時間需求就會一直改。今天加一個功能明天改一個邏輯測試用例剛寫完又要改。測試時間被壓縮質(zhì)量自然下滑。變更處理如果需求變更測試時間怎么調(diào)整是順延發(fā)布還是壓縮測試范圍這個規(guī)則要提前定好不要每次變更都臨時吵架。關(guān)鍵動作在版本啟動時就明確凍結(jié)時間和變更規(guī)則而不是等變更發(fā)生時才討論。提前定規(guī)則比時候吵架高效得多。三、跟運(yùn)維對齊環(huán)境可用性和發(fā)布流程核心接口環(huán)境維護(hù)責(zé)任發(fā)布檢查清單。環(huán)境維護(hù)測試環(huán)境誰維護(hù)出了問題找誰多久響應(yīng)環(huán)境不穩(wěn)定測試效率直接砍半。測試跑一半環(huán)境掛了等半天沒人修一天就過去了。這個責(zé)任要明確到人不能是“大家都可以找運(yùn)維”。發(fā)布檢查上線前確認(rèn)核心用例通過、遺留缺陷已知且可接受、回滾方案準(zhǔn)備好。這個清單由測試和運(yùn)維一起過確認(rèn)無誤再發(fā)。關(guān)鍵動作把環(huán)境維護(hù)責(zé)任人和發(fā)布檢查清單固定下來不要每次上線都臨時找人。固定流程比臨時協(xié)調(diào)靠譜。四、跨部門協(xié)作得核心不是“關(guān)系好”而是“接口清晰”很多測試管理者把跨部門協(xié)作理解為“搞好關(guān)系”。關(guān)系好當(dāng)然有幫助但關(guān)系不能替代規(guī)則。關(guān)系好的時候開發(fā)愿意幫你多跑一遍冒煙關(guān)系不好的時候冒煙不過就直接提測?？筷P(guān)系質(zhì)量是波動的靠規(guī)則質(zhì)量才是穩(wěn)定的。接口清晰的意思是雙方都知道對方要什么、什么時候要、達(dá)到什么標(biāo)準(zhǔn)。規(guī)則寫下來、雙方確認(rèn)、每次執(zhí)行都對照規(guī)則扯皮自然就少了。跨部門協(xié)作做得好不好不看你跟誰吃了多少次飯看你跟誰對齊了多少條規(guī)則。