我用技術語言跟老闆報告自動化測試，他聽了三分鐘就去開別的會

我用技術語言跟老闆報告自動化測試，他聽了三分鐘就去開別的會 目錄 1. 那次報告 2. 老闆想聽的和我說的完全不同 3. 把測試數字翻譯成業務語言 4. 業界怎麼說這件事 5. 我現在怎麼跟主管談自動化 6. 結尾 那次報告 那是我把 App 自動化跑起來之後第一次向主管報告成果。 我準備了一份投影片，裡面有：架構圖、Appium 版本、測試案例數量、CI 流程、locator 策略選擇邏輯。 我講了大概十分鐘，主管問了一個問題：「這個對我們的 release 有什麼幫助？」 我說：「可以減少手動測試的時間，CI 每次 push 都會自動跑。」 他點了點頭，說「好」，然後去接下一個會議了。 預算申請沒有下文。 老闆想聽的 我後來才搞清楚那次報告哪裡出了問題。 主管不是不在意品質。他在意的是： 這件事值不值得繼續投入資源 。 我給他的資訊全是技術語言：Appium、CI pipeline、locator strategy。這些對他沒有意義。他需要知道的是： 這個東西能省多少時間？ 省下的時間拿去做什麼更有價值的事？ 如果不做，會有什麼風險？ 多久之後投資才能回本？ 我的投影片一個都沒有回答到。 翻譯成業務語言 自動化測試的價值，要用老闆聽得懂的單位來說。 省下的時間 最直接的說法：一個 release cycle 原本手動 regression 要跑 3 天，自動化之後跑 2 小時。 但光說時間不夠，要說時間的成本：QA 人力時薪換算下來，一個 release cycle 省了多少錢？或者換個角度：省下的 3 天，QA 可以去做探索性測試、驗新功能，而不是重複跑一樣的東西。 更早發現 bug 的成本差距 這個數字說服力最強，但需要你自己去算： BetterQA 對多個企業的研究顯示，上線後才修的 bug 成本約是測試階段的 30 倍 。更廣為人知的「IBM 100x 說法」雖然原始出處有爭議，但方向是有現代研究持續驗證的：bug 越晚發現，成本越高，因為牽涉到 context switch、hotfix 部署、客訴處理、甚至品牌損失。 如果你能說「上個 quarter 自動化測試擋下了 X 個 bug，其中 Y 個是高風險的，如果這些在上線後才發現，估計要花多少時間和資源處理」，這才是主管能判斷的資訊。 Release 速度 自動化讓 CI 每次 push 都跑一次核心流程，等於把 regression 週期從「每次 release 前幾天」變成「每次 push 後幾分鐘」。問題更快被發現，修復窗口更長，release 更穩定。 這對主管的翻譯是： 更短的 release cycle、更少的 last minute 緊急修復 。 業界怎麼說這件事 這些不是只有我們面臨的問題，業界有數據支撐這件事的重要性。 自動化回本速度比多數人預期快 Katalon《State of Quality Report 2025》調查數千名工程師， 超過 50% 的公司在導入自動化測試的第一年內就看到正向 ROI ，其中 24% 幾乎是立即見效。這個數字告訴主管：這不是幾年後才回本的長期投資，多數公司一年內就能量化到效益。 市場在說話 Capgemini《World Quality Report 2024 25》調查全球超過 1,000 家企業，報告明確指出： 品質工程已經不再是後台支援功能，而是業務成功的核心驅動力 。同份報告顯示自動化採用率持續成長，企業已不再把測試自動化當成「side project」，而是主動投資的策略項目。 DORA 研究：品質和速度不衝突 Google 的 DORA 研究（2024 年版，調查超過 3 萬名開發者）追蹤了最頂尖的「Elite performer」團隊，這些團隊的部署頻率是表現最差團隊的 182 倍 ，同時 change failure rate 反而是他們的 8 倍低 。 也就是說，部署最快的公司，品質也最穩定。這和「快跟好只能選一個」的直覺完全相反——而讓他們做到這件事的基礎，正是完善的自動化測試。 這三個數據放在一起，對主管說的意思是：這不是 QA 在替自己爭取資源，是業界持續驗證的投資方向。 我現在怎麼跟主管談 第二次提自動化投資的時候，我沒有帶架構圖。我帶了這三個數字： 數字 1：每個 release cycle 省下的 QA 時數 「目前手動 regression 大約 X 小時，自動化之後預計降到 Y 小時。以現在的 release 頻率，一個月省 Z 小時。」 數字 2：近三個月自動化測試擋下的 bug 數 「其中有 N 個是 regression bug，也就是之前沒問題、這次改動導致的問題。這類 bug 如果沒被擋住，通常要到用戶回報才知道。」 數字 3：回本時間 「初期建置大概需要 A 小時投入。以每個 release cycle 省 B 小時計算，大約 C 個月可以回本，之後每個 cycle 都是純收益。」 這三個數字不需要很精確，但要來自真實的紀錄。如果你沒有紀錄，就從這次開始記。 一個常被忽略的說法：風險語言 除了省時間，另一個主管很在意的是 風險 。 自動化測試的價值不只是省時間，是「讓你在承擔壓縮 timeline 的壓力時，不是在賭博」。 如果主管說「這次 release 提早三天」，你能說：「好，我會根據風險矩陣調整測試範圍，確保核心流程的自動化測試至少跑完」，這讓他知道你不是隨便跳測試，而是有依據的取捨。 相反地，如果你沒有自動化，壓縮 timeline 的代價就是「跳測試」——而這個風險最後是公司承擔的。 結尾 那次報告之後，我花了一個月記錄真實數據：每次跑自動化省了多少時間、擋下了哪些 bug、哪些 bug 如果漏到 production 影響多大。 第二次報告用這些數字說話，主管聽了之後問的問題是「下一步要擴展哪些功能的自動化覆蓋率」。 不是技術沒有說服力，是技術語言說服不了做業務決策的人。 把你做的事翻譯成對方能用的資訊，是 QA 工作裡最常被低估的技能。 參考資料 BetterQA — Cost of fixing bugs by SDLC stage Katalon — State of Quality Report 2025 Capgemini — World Quality Report 2024 25 Google DORA — Accelerate State of DevOps Report 2024