測試的問題每間公司都有，但為什麼每間公司都沒解決

測試的問題每間公司都有，但為什麼每間公司都沒解決 有一類文章我看過很多次，大概長這樣： 「業界常見的測試問題： 一、功能測試和效能測試混在一起跑； 二、QA 不懂 CI/CD； 三、大家以為 QA 等於測試……」 每次看都覺得說得對。每次看完還是覺得沒有用。 不是因為文章寫得不好，而是因為—— 這些問題早就有人知道，但還是一直重演。 如果「知道問題是什麼」就能解決問題，這些問題早就不存在了。 所以這篇文章不是要再說一遍「這些問題是什麼」，而是想聊一個更核心的問題： 為什麼這些問題這麼難解？ 問題不缺答案，缺的是在對的時間出現的人 功能測試和效能測試混在一起跑——這是一個決策問題，不是知識問題。 很少有人真的不知道「功能驗證」和「效能量測」是兩件不同的事。問題是：在一個 sprint planning 裡，有沒有人在「這個 feature 要測什麼」被討論的當下，說出「我們先只做功能驗證，效能等下個階段再處理」這句話？ 通常沒有。 原因不是大家沒有這個知識，而是： 這個對話通常發生在 QA 不在場的時候。 功能的範疇、測試的策略、時間的分配——這些決策在 PM 和 RD 的討論裡就定下來了。QA 拿到的，是一張已經決定好的票單。 票單上不會寫「這次測功能就好，效能先跳過」，也不會寫「這次要同時驗效能」。QA 只看到「這個功能需要測試」。 然後出事了，才開始討論：「你怎麼沒有測到效能？」 「QA 等於測試」這個等號，是 JD 寫出來的 QA 包含測試，但測試不等於 QA——這個概念在業界已經講了很多年。 但為什麼在大多數公司，這兩件事還是被混在一起？ 因為招聘的時候就混在一起了。 打開任何一份 QA 工程師的 JD，你會看到： 撰寫測試案例 執行功能測試 回報 Bug 維護自動化腳本 沒有人在 JD 裡寫「建立品質標準」、「設計測試流程」、「評估需求可測試性」。 職位描述決定了別人對你工作的預期，也決定了你自己對工作的定義。 當一個 QA 工程師從入職第一天就被告知「你的工作是執行測試、回報 bug」，他不太可能在三個月後開始主動討論測試策略的制定。不是能力問題，是沒有人給他這個框架。 所以「QA 等於測試」這件事，根源不在 QA 不懂，而在整個組織從來沒有把 QA 放在「能影響品質策略」的位置上。 QA 不懂 CI/CD，但 CI/CD 從來沒有問過 QA 另一個常見的觀察是：QA 不了解部署流程、不懂 CI/CD、沒辦法從系統層面理解問題。 這個觀察是真的。但我覺得問題的方向說反了。 正確的問題不是「QA 為什麼不懂 CI/CD」，而是「CI/CD 管線是什麼時候、由誰設計的，QA 有沒有被問到意見」。 在大多數公司，CI/CD 的架構是由 DevOps 工程師或資深 RD 設計的，目標是「讓部署快一點、穩一點」。這是合理的。 但測試在 pipeline 裡的位置——哪些測試在 PR 合併前跑、哪些在部署後跑、失敗的時候誰被通知——這些決策裡，QA 的聲音通常缺席。 所以最後跑出來的 pipeline，是一個「有跑測試」的 pipeline，但不一定是一個「測試設計得好」的 pipeline。 QA 沒有懂 CI/CD，有時候是因為沒有人覺得 QA 需要懂。 一個讓我印象深刻的對話 我曾經和一個 RD 聊到自動化測試的覆蓋率。他問我：「你們的覆蓋率目標是多少？」 我說：「我們沒有設目標，但有幾個核心流程一定要涵蓋。」 他有點困惑：「那你怎麼知道測得夠不夠？」 這個問題讓我想了一下。 然後我意識到：他不是在質疑我，他只是沒有人告訴過他，覆蓋率本身不是品質的指標，只是一個參考用的訊號。 他學到的概念是「覆蓋率越高越好」，然後他把這個概念帶進了對測試的所有期待裡。 這不是他的錯。這是教育的問題，也是溝通的問題——沒有人在對的時間跟他說：覆蓋率只是地圖，不是領土。 這些問題的共同根源 把這幾個觀察放在一起看，我覺得有一個共同的根源： 測試相關的重要決策，很少在有 QA 的場合做出。 功能範疇在 PM 和 RD 討論完的時候就定了。 CI/CD 架構在 DevOps 設計完的時候就確定了。 QA 的職責在 JD 寫完的時候就被框住了。 測試的期望在 RD 學校或上一份工作的時候就形成了。 QA 是在這些決策完成之後才出現的——然後被要求解決這些決策帶來的所有問題。 這不是誰的錯。這是結構的問題。 那 QA 能做什麼？ 如果上面的分析是對的，那解法就不是「QA 應該更懂效能測試」或「QA 應該多學 CI/CD」，而是： 讓 QA 在這些決策發生之前就出現在對話裡。 具體來說，這意味著幾件事： 在 sprint 開始的時候問：「這個 feature 的測試目標是什麼？」 不是等票進來才開始規劃，而是在 planning 的時候就把測試策略的討論放進去。 在 CI/CD 被設計的時候說：「可以讓我看一下 pipeline 怎麼跑的嗎？」 不是要接管，而是要把「測試如何融入」這個問題放進設計的考慮裡。 在跟新加入的 RD 互動的早期，說清楚自己的工作是什麼。 不用等到他對「QA 是做什麼的」有了錯誤的概念，才去糾正。 這些行動很小，甚至有點平凡。但它們改變的是 QA 在決策流程裡出現的時間點。 早出現一點，很多問題就不會發生。 為什麼說比做難 講起來容易，但我知道實際上很難。 因為「讓 QA 更早進入討論」這件事，需要的不只是 QA 的主動，還需要其他人願意讓 QA 進來。 而這個「讓 QA 進來」，往往意味著這些人要改變他們對 QA 的預期——從「等我做完，你來測」變成「我們一起從一開始就討論品質」。 這個改變不容易，也不快。 但我觀察到的是：大多數工程師和 PM 對這個改變是開放的，只是沒有人跨出第一步。 而跨出第一步，通常要靠 QA 自己。 不是因為這是 QA 的責任，而是因為——在所有角色裡，QA 是最清楚「沒有這個對話會發生什麼事」的那個人。 常見問題 Q：公司裡的 QA 問題大家都知道，為什麼還是一直重演？ A：因為這些問題的根源是結構性的，不是知識性的。功能的測試策略、CI/CD 的架構、QA 的職責定義——這些重要決策在 QA 不在場的時候就定下來了。QA 是在決策完成之後才出現，然後被要求解決這些決策帶來的所有問題。知道問題是什麼，不等於有辦法改變它發生的結構。 Q：QA 等於測試工程師嗎？ A：QA 包含測試，但測試不等於 QA。測試是執行層面的活動，QA 還包括建立品質標準、設計測試流程、評估需求可測試性、影響開發決策。問題是大多數公司的 JD 只寫「撰寫測試案例、執行功能測試、回報 Bug」，這個定義從入職就把 QA 框進執行者的角色，很難走出去。 Q：QA 應該什麼時候介入開發流程？ A：越早越好。理想是在 sprint planning 時就參與「這個 feature 的測試目標是什麼」的討論，而不是等票進來才開始規劃。在 CI/CD 被設計的時候提出「測試如何融入」的問題，在 RD 對 QA 的認知還沒定型前說清楚自己的工作範疇。早出現一點，很多問題就不會發生。 Q：QA 怎麼開始提升在組織裡的影響力？ A：從「讓自己在決策發生之前出現在對話裡」開始。具體行動不需要很大：sprint planning 時主動問測試目標、pipeline 設計時請求了解架構、和新進 RD 早期說清楚 QA 的工作範疇。大多數工程師和 PM 對這個改變是開放的，只是沒有人跨出第一步——而 QA 是最清楚「沒有這個對話會發生什麼事」的那個人。 參考資料 Capgemini — World Quality Report 2024 25 — 全球 QA 困境與組織品質成熟度年度報告 Google DORA — State of DevOps 2024 — 技術實踐與組織文化對軟體交付效能的影響 ISTQB — Foundation Level Syllabus — 測試流程與角色定義的國際標準 Lisa Crispin & Janet Gregory — More Agile Testing — QA 在敏捷組織中的定位與困境 Michael Bolton — Testing vs Checking — 測試與檢查的根本差異，說明測試問題的深層原因