[{"data":1,"prerenderedAt":39},["ShallowReactive",2],{"article-zh-ai-development-sdlc-release-verification":3},{"article":4,"related":17,"prevArticle":36,"nextArticle":16,"availableLocales":37},{"id":5,"slug":5,"title":6,"excerpt":7,"content":8,"image":9,"date":10,"published":11,"status":12,"category":13,"keywords":14,"meta_description":15,"og_image":16,"custom_css":16,"created_at":10,"updated_at":10},"ai-development-sdlc-release-verification","當 AI 開發只要兩小時，驗證卻還要三天","AI 開發加速後，規格確認、測試與發布不會自動跟著變快。從一個預約系統 SaaS 的實際案例，談我們如何調整 SDLC，讓完整發布驗證從兩三天縮短到兩小時以內，以及 SQA 的角色如何跟著改變。","\u003Cp>最近半年，我們花了不少時間，協助不同客戶調整他們的軟體開發生命週期，也就是 SDLC。\u003C/p>\n\n\u003Cp>工作內容包含導入 AI 開發，但投入很多心力的地方，是整個流程怎麼調整，以及人在裡面的角色與職責，應該怎麼跟著改變。\u003C/p>\n\n\u003Cp>需求什麼時候需要確認？哪些決定應該在開發前完成？程式產出之後，怎麼知道它符合預期？誰有責任判斷這個版本能不能交付？\u003C/p>\n\n\u003Cp>這些都是原本就存在的問題。當開發速度大幅提高，它們對團隊的影響也跟著改變。\u003C/p>\n\n\u003Ch2>過去可以接受的等待，開始變成瓶頸\u003C/h2>\n\n\u003Cp>過去，對許多團隊來說，開發佔了交付過程中很大一部分的時間。\u003C/p>\n\n\u003Cp>需求確認之後，要有人把功能寫出來。這段時間裡，團隊還能補充細節、討論例外情境、準備測試，讓其他工作穿插進行。\u003C/p>\n\n\u003Cp>有些流程沒有安排得很完整，但靠著人的經驗與臨時補位，事情還是能繼續往前走。\u003C/p>\n\n\u003Cp>當 AI 開始承接更多開發工作，這個節奏就變了。\u003C/p>\n\n\u003Cp>程式可以很快產出，規格確認、測試與決策的速度，卻不會自動跟著提高。過去看似可以接受的等待，開始佔據交付過程中越來越大的比例。\u003C/p>\n\n\u003Cp>不同團隊，也因此遇到不同的問題。\u003C/p>\n\n\u003Ch2>測試薄弱的團隊，先感受到的是麻煩變多了\u003C/h2>\n\n\u003Cp>有些團隊原本的測試就比較薄弱。\u003C/p>\n\n\u003Cp>功能做好後，主要靠工程師自己試，或等使用者回報問題。驗收標準不夠明確，修改影響到既有功能時，也未必能及時發現。\u003C/p>\n\n\u003Cp>過去由人寫程式，這樣已經很辛苦。導入 AI 之後，麻煩的產生速度也跟著提高了。\u003C/p>\n\n\u003Cp>前一個功能還沒確認完，下一個功能已經做好。剛修好的問題，在另一次修改後又出現。每次都說完成了，但團隊始終沒有把握，現在這個版本到底能不能用。\u003C/p>\n\n\u003Cp>這時候，大家很容易產生一種感受：「AI 怎麼講不聽？」\u003C/p>\n\n\u003Cp>明明說過不能改的地方，為什麼又改了？已經確認過的規則，為什麼下一次又不符合？\u003C/p>\n\n\u003Cp>這裡面有工具本身的限制，也有流程需要處理的問題。那些已經講過的要求，有沒有被保留下來？不能壞掉的功能，有沒有持續被驗證？每次修改後，有沒有方法知道影響範圍？\u003C/p>\n\n\u003Cp>如果這些都還需要靠人重新記起、重新檢查，產出越快，人的負擔就越重。\u003C/p>\n\n\u003Ch2>規格確認太晚，來回修改就會更密集\u003C/h2>\n\n\u003Cp>另一種情況，是規格直到開發後期才逐漸被確認。\u003C/p>\n\n\u003Cp>一開始只有大方向，操作細節、權限、資料規則與例外情境，要等畫面做出來，大家才發現彼此想的不一樣。\u003C/p>\n\n\u003Cp>過去，工程師可能會在實作過程中停下來問，也可能憑經驗補上部分判斷。這些確認與協商，一直是開發工作的一部分，只是未必被明確安排在流程裡。\u003C/p>\n\n\u003Cp>AI 可以很快把模糊的需求做成一個版本。但空白被補上，不代表相關的人已經做過決定。\u003C/p>\n\n\u003Cp>於是，第一版出來要改，改完發現另一個情境沒考慮到，再改。新規則和舊規則衝突，又回頭調整。\u003C/p>\n\n\u003Cp>每一次修改都很快，整體卻未必更快完成。需要討論與決策的人，反而被更密集的確認工作追著跑。\u003C/p>\n\n\u003Cp>因此，團隊需要釐清：哪些事情應該先確認，哪些可以透過原型探索，以及由誰把討論收斂成可以實作與驗證的要求。\u003C/p>\n\n\u003Ch2>即使測試已經做得很多，還是可能跟不上\u003C/h2>\n\n\u003Cp>不過，驗證成為瓶頸，也不一定代表團隊原本做得不夠。\u003C/p>\n\n\u003Cp>這半年讓我們印象很深的一個例子，是一套預約系統 SaaS。\u003C/p>\n\n\u003Cp>他們支援多種業務模式，業務邏輯相當複雜。不同設定、操作流程與規則之間，存在許多需要一起確認的組合。\u003C/p>\n\n\u003Cp>他們原本就有自動化測試，也有人工作業。以我們接觸過的專案來看，自動化測試的覆蓋程度，已經屬於比較高的一群。\u003C/p>\n\n\u003Cp>當時，完整的一輪 release verification，大約需要兩到三天。\u003C/p>\n\n\u003Cp>在原本的開發節奏下，這是團隊能夠安排的驗證時間。但導入 AI 開發後，需求進來、討論規格、確認開發方案，再交由 AI 實作並完成基礎驗證，一批需求可能只需要一到兩個小時。\u003C/p>\n\n\u003Cp>這裡的基礎驗證，還不等於整個版本已經可以發布。\u003C/p>\n\n\u003Cp>當兩三批需求要一起進入 UAT 或正式環境時，團隊仍然需要確認這些變更放在一起，會不會影響既有的業務行為。\u003C/p>\n\n\u003Cp>於是，開發持續往前走，需求卻開始堆在發布前。\u003C/p>\n\n\u003Cp>原本可以接受的兩到三天，成了整個流程最明顯的瓶頸。\u003C/p>\n\n\u003Ch2>從兩三天，調整到兩小時以內\u003C/h2>\n\n\u003Cp>我們和這個團隊一起調整的範圍，包含開發流程、測試方式、測試案例，以及測試資源的安排。\u003C/p>\n\n\u003Cp>這些需要放在一起看。開發怎麼切分、變更怎麼交付、測試如何執行，以及有哪些資源可以支撐驗證，都會影響最後的速度與結果。\u003C/p>\n\n\u003Cp>調整過程中，API 與 UI 測試案例的合計數量，從原本的兩千六百多個，增加到一萬七千多個。\u003C/p>\n\n\u003Cp>案例增加了，整體驗證速度卻更快，抓到問題的比例也比以前更高。目前，完整的 release verification 流程，已經可以控制在兩個小時以內。\u003C/p>\n\n\u003Cfigure>\n  \u003Cimg src=\"https://cdn.sqa.tw/articles/ai-sdlc-verification-before-after.jpg\" alt=\"發布驗證調整前後的概念對照：原本兩到三天、兩千六百多個測試案例，調整後兩小時以內、一萬七千多個測試案例\" width=\"1672\" height=\"941\" loading=\"lazy\" />\n  \u003Cfigcaption>調整開發流程、測試方式與資源安排，讓驗證跟上開發節奏。通道為概念示意。\u003C/figcaption>\n\u003C/figure>\n\n\u003Cp>對這個團隊而言，這讓發布前的驗證，有機會重新跟上需求與開發的節奏。\u003C/p>\n\n\u003Cp>這個結果也提醒我們：導入 AI 開發的效益，需要從整個交付流程來看。當程式產出變快，後面的驗證與發布方式，也需要一起調整。\u003C/p>\n\n\u003Ch2>SQA 開始有機會往更前面走\u003C/h2>\n\n\u003Cp>我們沒有打算用這個案例回答「AI 能不能取代 SQA」。\u003C/p>\n\n\u003Cp>至少以目前的實務經驗來說，在控制得好的情況下，AI 確實可以承擔很多工作壓力，也能協助團隊交付更好的結果。\u003C/p>\n\n\u003Cp>當 SQA 不再需要把大量時間花在反覆執行與追趕驗證進度，就有更多空間參與更早期的工作。\u003C/p>\n\n\u003Cp>例如，在規格討論時辨識矛盾與遺漏，在實作之前建立驗收條件，或在變更範圍還小的時候，就讓問題被發現與處理。\u003C/p>\n\n\u003Cp>這時候，測試左移與 early defect detection，才有更具體的實踐空間。\u003C/p>\n\n\u003Cp>SQA 也可能承擔一部分過去由 PM 或 RD 處理的工作：協助釐清需求、補足業務規則、分析變更影響，讓團隊更早做出有依據的決定。\u003C/p>\n\n\u003Cp>角色之間的分工，需要依團隊能力與情境調整。但 SQA 確實有機會用更完整的產品視角，協助團隊提高交付品質。\u003C/p>\n\n\u003Ch2>案例持續增加，專業問題也持續改變\u003C/h2>\n\n\u003Cp>當然，這些調整都還在進行中。\u003C/p>\n\n\u003Cp>前面提到的一萬七千多個測試案例，在寫這篇文章的前一週，其實還只有一萬五千多個。\u003C/p>\n\n\u003Cp>需求、規格與原始碼增加得很快，測試案例也跟著快速成長。\u003C/p>\n\n\u003Cp>接下來需要持續處理的問題，是怎麼在維持覆蓋程度的同時，減少重複、低效或已經失去價值的測試，讓驗證速度與判斷品質都能維持下去。\u003C/p>\n\n\u003Cp>測試案例的數量，是這次調整過程的一部分。團隊仍然需要持續判斷：這些案例保護了哪些業務行為，能發現哪些風險，以及需要付出多少執行與維護成本。\u003C/p>\n\n\u003Cp>這些都是專業課題，也會隨著產品與開發方式持續演變。\u003C/p>\n\n\u003Cp>如果你的團隊也開始遇到類似情況——開發已經加快，規格確認、驗證或發布卻跟不上——歡迎\u003Ca href=\"/consultation\">與我們聯繫\u003C/a>，或透過與我們合作的專業顧問公司一起討論。\u003C/p>\n\n\u003Cp>從團隊實際卡住的地方開始，才有辦法找到適合自己的調整方式。\u003C/p>","https://cdn.sqa.tw/articles/ai-sdlc-verification-bottleneck-cover.jpg","2026-11-05T12:00:00+08:00",true,"published","perspective","AI 開發, SDLC, SQA, 發布驗證, release verification, 測試左移, early defect detection, 自動化測試","從預約系統 SaaS 的實戰經驗，談 AI 開發導入後的 SDLC 調整：測試案例從 2,600 多個增加到 17,000 多個，完整 release verification 從兩三天縮短至兩小時以內。",null,[18,24,30],{"id":19,"slug":19,"title":20,"excerpt":21,"image":22,"date":23,"category":13},"sme-guide-to-choosing-ai-agent","滿街都是AI Agent，中小企業應該怎麼選？","我們最近被委託做 AI Agent 導入後的全盤檢查，才發現 Agent 在客服收單環節默默多採購了五倍原料，還差點在財務面造成流動性風險。Agent 的問題，往往不是不夠聰明，而是沒有人問對問題。","https://cdn.sqa.tw/articles/sme-agent-black-box-inspection.jpg","2026-09-01T15:00:00+00:00",{"id":25,"slug":25,"title":26,"excerpt":27,"image":28,"date":29,"category":13},"ai-coding-team-collaboration-three-patterns","AI coding 進到團隊之後，我們開始看到的三個現象","這半年接觸十多個開發團隊後，我們反覆看到同一件事：個人因 AI 變快，不代表團隊已經準備好一起變快。","/images/blog/ai-coding-teams-editorial.jpg","2026-08-20T08:00:00+00:00",{"id":31,"slug":31,"title":32,"excerpt":33,"image":34,"date":35,"category":13},"why-we-are-reintroducing-dbam-ai","為什麼我們重新整理 SQA.TW","這次 SQA.TW 改版，不是離開 SQA，而是讓網站更完整地呈現我們一直在做的事：理解企業營運、找出數位化與 AI 能真正發揮作用的位置。","https://cdn.sqa.tw/articles/1787077891011-ga9zk8zxnf.jpg","2026-08-17T16:00:00+00:00",{"slug":19,"title":20,"date":23},[38],"zh",1793852237835]