從瀑布式到敏捷開發，我們已經見證過一場開發速度與測試節奏的大洗牌。當年敏捷強調「及早回饋、快速調整」，雖然初期讓 QA 不堪負荷，但透過流程與責任的重新分配，終究逐漸穩定下來。
如今，GenAI 再次推動開發節奏飛快前進，開發者在數小時內就能生成一個功能原型，測試人員卻來不及理解需求，更遑論寫完自動化測試。這不是第一次速度革命，但衝擊可能是前所未有的。面對這場新挑戰，我們必須重新思考測試在開發流程中的位置與策略。
一、歷史的回聲：敏捷開發如何衝擊測試
當初敏捷（Agile）推行時強調「快速回饋、快速迭代」，於是原本半年甚至一年才交付的瀑布式流程，被切成了每兩週交付的 Sprint。但這帶來的問題是：
- 測試的時間被大幅壓縮：開發在最後幾天才交出功能，測試常常只能在極短時間內完成驗收與回歸。
- 測試活動頻率上升：每兩週都要做一次完整的回歸測試（甚至是每日），導致沒有自動化根本無法應對。
- 自動化變成生存需求：單元測試、TDD、CI/CD 被導入，就是要減輕測試人員的壓力，讓開發者自己多做些測試。
這波轉變逼得 QA 必須提升技能、學會自動化，同時也促使 RD 承擔更多測試責任。
二、GenAI 時代的第二波震盪：更快，但也更危險
進入 GenAI 時代，我們面臨的是比 Agile 更劇烈的變化：
- 開發輸出速度爆炸：AI 協助開發工具（如 Cursor、GitHub Copilot、Windsurf）讓 RD 可以在數小時甚至數分鐘產出功能原型。
- 測試人員還沒反應就要上線：速度快到 QA 根本還沒搞懂產品邏輯，RD 就要上 Production。
- 需求更模糊、更頻繁變動：GenAI 帶來的是「邊做邊改、邊試邊上」，需求不再穩定，測試條件變成流動目標。
- 測試成本外部化給使用者：很多產品直接交由市場「實驗」，這讓 QA 更難保障品質。
這些狀況讓 QA 面臨幾乎是 不可承受之快。
三、重新調整測試流程的關鍵：責任分攤與流程重構
既然 GenAI 的速度是不可逆的，我們就得像當年面對敏捷一樣重新調整流程與責任分工：
1. 測試責任前移至 RD
- GenAI 生成的程式碼更需要 RD 自己做基本驗證
- 實施單元測試、自動化回歸、TDD（甚至是 Prompt-Driven TDD）
- 讓 RD 成為測試的第一線守門員
- 不能只「寫出來」，還要「驗證過」
2. QA 不再只是驗收，而是「測試設計者 + 風險顧問」
- QA 的價值要轉移到「測試策略設計」、「風險識別」、「探索性測試」、「AI 回饋調校」等更高層次的工作上
3. 流程與工具的重新設計
- Spec by Example 來統一語言與驗收準則
- Pair Testing 與 RD 共創理解與驗證
- 探索性測試 session 融入開發節奏
- AI 協作工具 協助設計 test case 而非只自動生成 code
四、結語：面對新速度，我們需要新思維
敏捷當年已經讓測試部門歷經一次劇變，現在 GenAI 正在重演一次「更快、更模糊、更危險」的變化劇碼。
如果我們還是用過去的 QA 責任、測試流程來應對現在的開發速度，勢必會被壓垮。真正的調整，應該是：
不是測試要變快，而是整個「驗證思維」要前移、要共擔、要重設。
這場「速度革命」，不是 QA 一個角色能承擔的，而是整個團隊文化與流程的共同重構。
發表迴響