QA 是瓶頸，還是觸媒？全團隊持續測試的真正意義

QA 是瓶頸，還是觸媒？全團隊持續測試的真正意義 「測試要等 QA，QA 是瓶頸。」 這句話我聽過很多次，也說過很多次。有時候是抱怨，有時候是辯護。但課程講師 Lisi Hocke 的親身故事讓我第一次真的停下來想：如果 QA 一直是個關卡，問題是在人還是在流程？ 這篇是我上完 Test Automation University 上 The Whole Team Approach to Continuous Testing 的完整筆記。這門課不講工具，講的是「測試這件事應該怎麼在團隊裡被組織」。 課程概覽 課程名稱 ：The Whole Team Approach to Continuous Testing 平台 ：Test Automation University（免費） 章節 ：7 章 講師 ：Lisi Hocke 持續測試（Continuous Testing）是什麼？ 課程一開始蒐集了幾個定義，其中我覺得 Jez Humble 說得最有力： 「為了把品質內建到軟體中，我們需要採取不同的方法。我們的目標是在整個交付過程中，持續地運行多種類型的測試，包含手動和自動。」 而 Dave Farley 和他的 Continuous Delivery 書裡更直接： 「測試是跨職能的活動，需要整個團隊參與，並且應該從專案一開始就持續進行。」 持續測試不等於「把所有測試放進 CI」。那只是持續測試的一個工具，不是全部。 Dan Ashby 的模型說得好：在 DevOps 的每個環節——計畫、開發、建置、測試、部署、運維——測試都可以、也應該存在。測試是一種活動，不是一個階段。 為什麼這件事重要？ 有兩個維度： 速度 ：在 CI/CD 的環境裡，如果測試是最後一道關卡，你的回饋週期就取決於測試的速度。越晚發現問題，修復成本越高。 品質 ：品質不是可以在最後「加進去」的東西。如果你等到功能做完才開始想測試，你已經錯過了很多可以影響設計決策的機會。 QA 當關卡，會發生什麼事？ 講師 Lisi 分享了她自己的故事，讀了讓我很有共鳴。 她同時負責兩個團隊的測試，某段時間還代理了一個 PO 五週的休假。三個角色加在一起，她變成了每件事的瓶頸。測試票卡在她手上，兩個團隊都動不了。 結果是什麼？ 她只能一張票接一張票地追，根本沒有時間思考 測試品質下降（只能快速掃過，不能深思） 團隊的 velocity 降低，但工作卡在 WIP 越積越多 沒有時間做技術改善、沒有時間做跨團隊協作 最後兩個團隊都意識到這樣下去不行，才開始思考改變。 這個故事的關鍵不是「Lisi 不夠努力」，而是 流程本身把 QA 設計成了關卡 ，這在本質上就會產生瓶頸。 瓶頸的解法：整個團隊測試 全團隊測試（Whole Team Approach）的核心概念： 測試不只是 QA 的責任，它是整個團隊共同的責任。 這來自敏捷測試象限（Agile Testing Quadrant）的思想。測試不是某個人的工作，而是一種流動的活動，貫穿整個開發過程，由不同角色在不同時間點進行。 開發者寫 unit test、做 code review QA 設計測試策略、做探索性測試、輔助自動化 PO 確認 AC 是否反映業務需求 UX 設計師驗證使用者流程是否符合設計意圖 每個人在自己最有能力的地方貢獻，而不是把所有驗證都推到最後一個「QA 關卡」。 沒有自動化專家，怎麼辦？ 這是很現實的問題。很多團隊想要自動化測試，但沒有人有足夠的自動化能力。 課程的建議： 學習的起點不是工具，是風險 。你的系統最大的風險在哪裡？那個地方才是自動化最有價值的地方。如果沒有任何 unit test，不要先衝 performance testing；如果最大的問題是核心流程常 regression，就先從那裡下手。 學習不是一個人的事 。一個人試圖自學自動化，非常難堅持。不是因為懶，而是因為學習需要回饋——你做對了嗎？做錯了嗎？有沒有更好的方式？一個人學很難得到即時的回饋。 配對學習（Pair Learning）效果更好 。找一個願意一起學的人，即使兩個人都是新手，也比一個人悶頭學好。因為你們可以互相提問、互相解釋，解釋的過程本身就是最有效的學習。 三種工作模式 課程用了很多篇幅討論協作模式，這是整門課最有意思的部分。 模式一：Solo（單獨作業） 大多數人預設的工作模式：我做我的，你做你的。 Solo 的問題不是「效率低」，而是 它產生了資訊孤島和等待時間 。 一個常見的場景： 每一次 context switch 都有成本。每一段等待時間都是浪費。WIP（Work in Progress）越積越多，流動速度越來越慢。 Solo 模式在工作量少、任務簡單的時候可以運作，但隨著複雜度提高，它的缺點會被放大。 模式二：Pairing（配對） 兩個人同時在同一個任務上工作。 配對有兩種主要風格： 傳統配對 ： 一個人打字（Driver），一個人觀察（Observer） 有想法的人請求拿回鍵盤 缺點：觀察者容易走神、失去投入感 強配對（Strong Style Pairing） ： 一個人打字（Driver），一個人導航（Navigator） 有想法的人要 把鍵盤交給對方 ，讓對方執行 核心規則：「凡是在鍵盤上執行的，必須先通過 Driver 的腦袋」 強配對的好處是讓知識真正傳遞。你不能只說「去那個 function 改第三行」，你要說清楚「我想做什麼」，讓對方理解後再執行。這個過程強迫了共同理解。 配對的好處： 減少知識孤島（只有一個人懂這段 code 的風險） 即時回饋（不需要等 code review） 減少等待時間（兩個人一起把一件事做完，再移到下一件） 配對確實很消耗精力，建議定時休息。 模式三：Mob（群體協作） Mob Programming 由 Woody Zuill 的團隊發展出來，概念很簡單： 「所有聰明的人，同時在同一件事情、同一個地方、同一台電腦上工作。」 Mob 的結構和強配對相似，但有多個人： Driver ：只有一個，負責打字，只執行 Navigator 的指令 Navigator ：當前負責導航的人，說出下一步的意圖 Mob ：其他人，可以研究、提建議、準備接手 Navigator 關鍵原則： 說最高層次的意圖 ：先說「我想做什麼」，如果 Driver 不懂，再說「去哪裡」，最後才說「打什麼字」 輪換頻繁 ：依時間（例如每 10 分鐘）或依任務完成輪換 Yes, and... ：借鑒即興劇的規則，不要否定他人的想法，而是在上面延伸 Mob 特別適合： 困難的技術問題（多個人的知識加在一起） 知識傳遞（新人可以在 mob 裡快速學習） 複雜的設計決策（多角度同時參與） Mob 不是永遠都用。它耗費人力，適合用在高價值、高複雜度的任務上。 不只是工作方式，還有文化 課程最後提到幾個能支持全團隊測試的文化和實踐： BDD（行為驅動開發） ：在功能開發前，用例子定義期望行為。讓 PO、開發、QA 三方在「做什麼」上達成共識，然後這些例子可以直接轉化成自動化測試。 零缺陷容忍（Zero Defect Tolerance） ：發現問題立刻確認是不是真的 bug、值不值得修。是的話直接在當前 sprint 解決，不是的話關掉。不要讓 bug backlog 累積成堆，那只是把問題堆在角落假裝沒看見。 T 型人才 ：每個人都有深度（自己的專業），但也要有廣度（能幫到其他領域）。QA 懂一些 code、開發者能做基礎測試，這樣的團隊流動性更好，也更不容易被單一角色卡住。 我的總結 這門課讓我重新思考了一個問題： QA 的角色是守門員，還是教練？ 守門員的模式：功能做完了，交給我，我說行才能上。這個模式讓 QA 成為瓶頸，也讓品質變成 QA 一個人的責任。 教練的模式：在整個過程中，幫助團隊理解測試的視角，讓每個人都能做出品質更好的決策。QA 不消失，但工作重心從「把關」轉移到「賦能」。 當然，實際情況取決於團隊和組織的脈絡。課程最後說得很實在：「It depends。」每個故事都是獨特的，只有在你自己的脈絡裡實驗，才能知道什麼有效。 但至少，知道有這些選項存在，是改變的第一步。 課程連結：TAU The Whole Team Approach to Continuous Testing 參考資料 Test Automation University — Whole Team Approach to Continuous Testing — 本文課程來源，Lisi Hocke 主講 Lisa Crispin & Janet Gregory — Agile Testing: A Practical Guide — 敏捷測試聖經，全團隊品質概念出處 Agile Alliance — Whole Team — 全團隊概念定義 Google DORA — State of DevOps 2024 — 持續測試與部署頻率的關聯研究 Ministry of Testing — Continuous Testing — 持續測試實務指南