2025 年 7 月,Thoughtworks 發表了一份實驗性研究,標題是《AI-generated test cases from user stories: An experimental research study》。研究設計很單純:三位有 3-5 年經驗的 QA 工程師,針對九個不同複雜度的 user story,分別用手寫跟 AI(GitHub Copilot 跟 ChatGPT)產生 test case,然後用八個指標量化比較。
我會把這份研究單獨拉出來談,是因為市面上多數討論 AI 測試的內容都停留在「AI 很厲害」或「AI 不能取代人」這種一面倒的論述。Thoughtworks 這份研究難得的地方在於:它把 AI 跟人在 test case design 上的差距,具體量化成數字。
而這些數字,比抽象的好壞論述,更能告訴我們現在這個時間點該把力氣花在哪裡。
這篇我想做的事是把研究的關鍵發現拆給你看,並解讀這些發現對 RD 和 QA 團隊的實際意義。
第一個發現:AI 真的快,但「快的是初稿」
研究最亮眼的數字是時間效率 80.07%——AI 平均只需要手動產出五分之一的時間就能完成 test case。
這個數字會被很多人拿來支持「AI 可以取代 QA」的結論,但這個解讀其實偏離了研究本意。
研究中明確提到,AI 在這個速度下產出的是「rapid initial draft」——快速初稿。這份初稿的結構一致性高達 96.11%,功能性需求覆蓋也很好,但它離可以直接進 production 的 test case,還有一段距離。
這個區別很重要。如果你是 RD 或 QA Lead,讀到「省 80% 時間」就直接推論「人力可以縮編」,你會踩到坑。真正的意涵是:AI 把 test case design 的「打草稿」階段壓縮了五倍,但「審稿、修稿、補洞」的階段沒有變短。
換言之,AI 重新分配了 QA 工作的成本結構,而不是消除了它。
第二個發現:27.22% 的歧義率,才是真正該關注的數字
研究中有一個數字常被略過,但我覺得是整份研究最重要的訊息:AI 生成的 test case 中,27.22% 存在歧義(ambiguity score)——也就是測試步驟不清楚、預期結果不明確,需要人為介入釐清。
打開計算機算一下:每四個 AI 產出的 test case,大約就有一個是「看起來像 test case,但實際上沒辦法直接執行」的狀態。
這個數字之所以重要,是因為它揭露了一件事:AI 的產出在「形式」上很像 test case,但在「語意」上常常不夠精確。 而 test case 的價值正好建立在語意精確上——一個「點擊按鈕後應該成功」這種模糊的 expected result,跟「點擊按鈕後,訂單狀態應從 PENDING 變為 CONFIRMED,且使用者收到確認 email」這種具體的 expected result,在執行價值上是天差地遠的。
這個落差,直接定義了 test case design 在 AI 時代的人類價值:幫 AI 產出的草稿,把語意補滿、把模糊的地方釐清、把缺漏的判斷標準補上。
這不是體力活,是設計活。
第三個發現:同樣是 AI,「會下指令」跟「不會下指令」差快七成
整份研究中我覺得最有戰略意義的發現,是 prompt 優化帶來的改善幅度——67.78% 平均提升。
研究中給出兩個 prompt 對照:
- 初始版本:「Generate test cases for this user story.」
- 優化版本:「Acting as a Senior QA Engineer, generate comprehensive test cases following the specified template format. Include functional, boundary value, error handling and edge case scenarios. Use Given/When/Then format where appropriate.」
兩個 prompt 之間的差異,本質上不是「AI 用得熟不熟」,而是對 test case design 方法論熟不熟。
優化版本之所以效果好,是因為它做了三件事:
- 指定角色與標準:Senior QA Engineer 這個角色設定,讓 AI 對齊更高的品質標準
- 明確列出測試類型:functional、boundary value、error handling、edge case——這些正是傳統 test case design 教科書裡的核心概念
- 指定輸出格式:Given/When/Then 是 BDD 的標準結構,有利於後續驗證
這意味著,懂 test case design 方法論的人,用同一個 AI,產出品質會比不懂的人高 67.78%。這是一個非常具體的競爭差距。在 AI coding 時代,這個差距不會因為模型變強而縮小——因為模型再強,你不會用它要的指令,它就無法針對你的需求最佳化。
換句話說:AI 沒有讓 test case design 的方法論變過時,反而讓它變成 prompt 工程的核心能力。
第四個發現:AI 在某些情境下,確實比人想得更全
有一個容易被「捍衛 QA 價值」的論述帶過的數據,我覺得不應該被忽略:研究中正確率(correctness)的範圍是 62.5%-130%,最高分超過 100%。
研究的註解講得很清楚:「Scores above 100% indicate cases where AI generated more comprehensive test cases than the manual baseline.」也就是 AI 在某些情境下,產出的 test case 比人工版本還更完整。
這件事該怎麼解讀?
我認為這個數據的意思不是「AI 比人厲害」,而是「人在重複性高、模式明顯的場景下,容易因為疲勞或想當然耳而漏掉 case」。AI 不會疲勞,而且它讀過的 test case 樣本可能比任何單一工程師都多。在簡單到中等複雜度的場景,它確實能產出比個別工程師更完整的覆蓋。
對 QA 工程師來說,這是一個誠實面對的時刻:你最值錢的部分,不是「想得到所有的 case」,而是「想得到 AI 想不到的那些 case」。
第五個發現:AI 的死角,正是人最值錢的地方
研究中明確列出 AI 的四個限制,這四點放在一起看,基本上就是 RD 跟 QA 在 AI 時代的職涯地圖:
- 對輸入品質高度依賴——需求講得不清楚,AI 就產不出好 test case
- 難以解讀複雜業務邏輯——跨系統、跨狀態、有歷史包袱的業務規則,AI 跟不上
- 進階測試技巧未被適當應用——等價類劃分、決策表、狀態轉移這類方法論,AI 不會主動套用,除非你叫它套
- 非功能性測試覆蓋有限——效能、安全、可用性、相容性這類議題,AI 在沒有明確指示下幾乎不會處理
這四點的共同點是:它們都需要對「這個專案、這個業務、這個系統」的具體理解,而不是對「軟體測試」的通用知識。
而這四點,正是一個資深 RD 或 QA 工程師長期累積下來、最值錢的部分。
從這個角度看,Thoughtworks 的研究其實在告訴我們一個比較精細的訊息:AI 拿走的是「通用的 test case 模板」這層工作,但「把模板填上你公司業務血肉」這層工作,留給了人。後者的單位價值,反而因為 AI 把前者變便宜了而上升。
對 RD 和 QA 團隊的三個實際意涵
把上面五個發現綜合起來,我認為可以推導出三個對工作有用的判斷。
第一,你需要從「寫 test case」的執行者,變成「審 test case」跟「設計 prompt」的決策者。 27.22% 的歧義率代表你的角色從生產線變成品管線——AI 提供大量初稿,你負責把它們變成可執行的高品質產出。這個角色轉換,需要的能力跟過去不太一樣,但價值更高。
第二,投資 test case design 方法論的 ROI,在 AI 時代是上升的,不是下降的。 67.78% 的 prompt 優化提升,本質上是「懂方法論的人」對「不懂方法論的人」的競爭差距。等價類、邊界值、決策表、狀態轉移這些東西不是過時的學院派理論,而是直接決定你 AI 產出品質的工具。
第三,你的差異化會建立在「AI 想不到的那些 case」上。 AI 已經能 cover 大多數的標準 test case,你能加上的價值,是那些只有「在這家公司、做過這個系統、踩過這個雷」的人才會想到的情境——歷史包袱、跨團隊邊界、奇特的使用者行為、非功能性需求。這些是無法被通用 AI 取代的部分,也是你應該刻意去累積跟強化的部分。
結語
Thoughtworks 這份研究的價值,不在於它告訴我們 AI 強不強,而在於它把「AI 跟人在 test case design 上的具體差距」量化出來。
數字說了三件事:AI 真的快、AI 真的不夠精確、會用 AI 的人比不會用的人強七成。
這三件事拼在一起,結論不是「test case design 不重要了」,而是「test case design 從一個專業領域,變成 AI 時代每個 RD 都應該具備的核心能力」。
過去這項能力可能藏在 QA 部門裡。在 AI coding 把寫 code 變便宜之後,它正在被推到每個工程師的桌上。
研究出處
Yang Zhao, Vy Nguyen, Thuc Van Hoang. (2025, July 30). AI-generated test cases from user stories: An experimental research study. Thoughtworks Insights Blog.
發表迴響