最近半年，我們花了不少時間，協助不同客戶調整他們的軟體開發生命週期，也就是 SDLC。
工作內容包含導入 AI 開發，但投入很多心力的地方，是整個流程怎麼調整，以及人在裡面的角色與職責，應該怎麼跟著改變。
需求什麼時候需要確認？哪些決定應該在開發前完成？程式產出之後，怎麼知道它符合預期？誰有責任判斷這個版本能不能交付？
這些都是原本就存在的問題。當開發速度大幅提高，它們對團隊的影響也跟著改變。
過去可以接受的等待，開始變成瓶頸
過去，對許多團隊來說，開發佔了交付過程中很大一部分的時間。
需求確認之後，要有人把功能寫出來。這段時間裡，團隊還能補充細節、討論例外情境、準備測試，讓其他工作穿插進行。
有些流程沒有安排得很完整，但靠著人的經驗與臨時補位，事情還是能繼續往前走。
當 AI 開始承接更多開發工作，這個節奏就變了。
程式可以很快產出，規格確認、測試與決策的速度，卻不會自動跟著提高。過去看似可以接受的等待，開始佔據交付過程中越來越大的比例。
不同團隊，也因此遇到不同的問題。
測試薄弱的團隊，先感受到的是麻煩變多了
有些團隊原本的測試就比較薄弱。
功能做好後，主要靠工程師自己試，或等使用者回報問題。驗收標準不夠明確，修改影響到既有功能時，也未必能及時發現。
過去由人寫程式，這樣已經很辛苦。導入 AI 之後，麻煩的產生速度也跟著提高了。
前一個功能還沒確認完，下一個功能已經做好。剛修好的問題，在另一次修改後又出現。每次都說完成了，但團隊始終沒有把握，現在這個版本到底能不能用。
這時候，大家很容易產生一種感受：「AI 怎麼講不聽？」
明明說過不能改的地方，為什麼又改了？已經確認過的規則，為什麼下一次又不符合？
這裡面有工具本身的限制，也有流程需要處理的問題。那些已經講過的要求，有沒有被保留下來？不能壞掉的功能，有沒有持續被驗證？每次修改後，有沒有方法知道影響範圍？
如果這些都還需要靠人重新記起、重新檢查，產出越快，人的負擔就越重。
規格確認太晚，來回修改就會更密集
另一種情況，是規格直到開發後期才逐漸被確認。
一開始只有大方向，操作細節、權限、資料規則與例外情境，要等畫面做出來，大家才發現彼此想的不一樣。
過去，工程師可能會在實作過程中停下來問，也可能憑經驗補上部分判斷。這些確認與協商，一直是開發工作的一部分，只是未必被明確安排在流程裡。
AI 可以很快把模糊的需求做成一個版本。但空白被補上，不代表相關的人已經做過決定。
於是，第一版出來要改，改完發現另一個情境沒考慮到，再改。新規則和舊規則衝突，又回頭調整。
每一次修改都很快，整體卻未必更快完成。需要討論與決策的人，反而被更密集的確認工作追著跑。
因此，團隊需要釐清：哪些事情應該先確認，哪些可以透過原型探索，以及由誰把討論收斂成可以實作與驗證的要求。
即使測試已經做得很多，還是可能跟不上
不過，驗證成為瓶頸，也不一定代表團隊原本做得不夠。
這半年讓我們印象很深的一個例子，是一套預約系統 SaaS。
他們支援多種業務模式，業務邏輯相當複雜。不同設定、操作流程與規則之間，存在許多需要一起確認的組合。
他們原本就有自動化測試，也有人工作業。以我們接觸過的專案來看，自動化測試的覆蓋程度，已經屬於比較高的一群。
當時，完整的一輪 release verification，大約需要兩到三天。
在原本的開發節奏下，這是團隊能夠安排的驗證時間。但導入 AI 開發後，需求進來、討論規格、確認開發方案，再交由 AI 實作並完成基礎驗證，一批需求可能只需要一到兩個小時。
這裡的基礎驗證，還不等於整個版本已經可以發布。
當兩三批需求要一起進入 UAT 或正式環境時，團隊仍然需要確認這些變更放在一起，會不會影響既有的業務行為。
於是，開發持續往前走，需求卻開始堆在發布前。
原本可以接受的兩到三天，成了整個流程最明顯的瓶頸。
從兩三天，調整到兩小時以內
我們和這個團隊一起調整的範圍，包含開發流程、測試方式、測試案例，以及測試資源的安排。
這些需要放在一起看。開發怎麼切分、變更怎麼交付、測試如何執行，以及有哪些資源可以支撐驗證，都會影響最後的速度與結果。
調整過程中，API 與 UI 測試案例的合計數量，從原本的兩千六百多個，增加到一萬七千多個。
案例增加了，整體驗證速度卻更快，抓到問題的比例也比以前更高。目前，完整的 release verification 流程，已經可以控制在兩個小時以內。
對這個團隊而言，這讓發布前的驗證，有機會重新跟上需求與開發的節奏。
這個結果也提醒我們：導入 AI 開發的效益，需要從整個交付流程來看。當程式產出變快，後面的驗證與發布方式，也需要一起調整。
SQA 開始有機會往更前面走
我們沒有打算用這個案例回答「AI 能不能取代 SQA」。
至少以目前的實務經驗來說，在控制得好的情況下，AI 確實可以承擔很多工作壓力，也能協助團隊交付更好的結果。
當 SQA 不再需要把大量時間花在反覆執行與追趕驗證進度，就有更多空間參與更早期的工作。
例如，在規格討論時辨識矛盾與遺漏，在實作之前建立驗收條件，或在變更範圍還小的時候，就讓問題被發現與處理。
這時候，測試左移與 early defect detection，才有更具體的實踐空間。
SQA 也可能承擔一部分過去由 PM 或 RD 處理的工作：協助釐清需求、補足業務規則、分析變更影響，讓團隊更早做出有依據的決定。
角色之間的分工，需要依團隊能力與情境調整。但 SQA 確實有機會用更完整的產品視角，協助團隊提高交付品質。
案例持續增加，專業問題也持續改變
當然，這些調整都還在進行中。
前面提到的一萬七千多個測試案例，在寫這篇文章的前一週，其實還只有一萬五千多個。
需求、規格與原始碼增加得很快，測試案例也跟著快速成長。
接下來需要持續處理的問題，是怎麼在維持覆蓋程度的同時，減少重複、低效或已經失去價值的測試，讓驗證速度與判斷品質都能維持下去。
測試案例的數量，是這次調整過程的一部分。團隊仍然需要持續判斷：這些案例保護了哪些業務行為，能發現哪些風險，以及需要付出多少執行與維護成本。
這些都是專業課題，也會隨著產品與開發方式持續演變。
如果你的團隊也開始遇到類似情況——開發已經加快，規格確認、驗證或發布卻跟不上——歡迎與我們聯繫，或透過與我們合作的專業顧問公司一起討論。
從團隊實際卡住的地方開始，才有辦法找到適合自己的調整方式。