小編精選 - 技術文章翻譯 · 05月24日

思考為什麼那麼可靠的 AI 會寫出這麼糟糕的測試案例

前言

我是 NewsPicks 的 QA 工程師西薗（@yurizono）。這篇文章要談的是我正在推進的 AI4QA。

那位 LLM 先生明明比我還會寫出更紮實的程式碼，可是一旦變成像 QA 的任務，就顯得不太可靠。這究竟是因為我身為 QA 工程師，對自己的工作抱有自豪感，還是其實有什麼原因導致它表現不佳呢？用一句話總結我最後得到的結論，就是：「缺少針對產品特化的脈絡整理。」

QA 團隊的現況

我們 QA 團隊有時也會做測試，但主要活動其實是提供工具與完善基礎建設，也就是從開發者的開發流程著手，目標是提升品質。

今年年初，SRE 與 QA 團隊合併，我個人也開始把觸角伸向 SRE 領域，因此做了 NewsPicks Web 版的基礎架構改善。雖然我寫著不熟悉的 CDK、進行不熟悉的基礎架構發布，還因此幾次引發事故（換了位置就不一樣了……）。在這個過程中，我自己也像開發工程師一樣把 AI 用到極致，總算稍微理解大家在用的 Claude Code 到底是什麼。結論就是：我作為程式撰寫者的存在意義，已經所剩無幾。這是贏不了的。

在這段以見習 SRE 身分玩得很開心的日子裡，我心想是時候把這個可靠的 AI 用回本業了，所以從今年春天開始，我展開了新的活動。那就是 AI4QA（AI for QA）。簡單說，就是把 AI 用在 QA 流程中。我想談的是我在這方面的做法——這在開發現場或許已經是理所當然的概念，但這是我自己的嘗試。

問題意識

我曾經把專案會議紀錄和規格書當作輸入，讓 AI 產生測試案例。結果它確實產出了看起來有點像測試案例的內容，讓我覺得很方便；但實際一 review，就會零星發現一些觀點遺漏。那時我一方面有點失望，覺得人類的工作還不會消失，另一方面也開始思考：要怎麼做才能讓它產出令人滿意的品質？於是展開了一連串嘗試與摸索。

我發現的事

如開頭所述，我意識到的關鍵是：「缺少針對產品特化的脈絡整理」。

以前面那個專案為例，雖然專案內容的脈絡大致齊備，但除此之外、也就是專案外部的脈絡卻不足。換句話說，AI 能理解接下來要做的功能是什麼，也能為此產出測試案例；但至於有沒有考慮到對既有功能的影響、是否漏掉了規格書中未提及的使用者類型，就明顯不足了。

什麼是脈絡（context）

這裡所說的「脈絡」，我的理解是：直接丟給 LLM 的指示文字叫做「prompt」，除此之外，LLM 讀進去或理解的一切都叫做「脈絡（context）」。如果拿人類來比喻，prompt 就像工作指派，而脈絡則像是「把資深員工的知識灌輸給新人的 onboarding 資料」。也就是各種工作前提所需的知識。

近來的 LLM 我認為是很優秀的工程師；如果有程式碼庫，且能把規格好好傳達給它，那麼至少對我這種等級的開發者而言，它已經到了可以把整個 coding 工作交出去的程度。程式撰寫者失業似乎已無法避免。另一方面，至今還沒聽說 QA 要失業。這裡就存在不對稱性。

之所以能把 coding 交給它，並不是因為「它寫程式的速度超越人類」，也不是因為「coding 是單純的工作」。之所以能交給它，是因為在 coding 的情境下，我們提供給 LLM 的是程式碼，而且「只要讀程式碼，就能知道那段程式在做什麼」。如果只限定在 What，那答案就在那裡。

當然，依照團隊組成不同，應採用的設計也會不同；而且一定也有許多無法完全表現在程式碼裡的設計理念，所以很多時候仍需要程式碼之外的知識1。我想現在大多是由人類透過 PR review 等方式補上這些知識，但至少在現階段，「LLM 作為程式撰寫者是可用的」這點已無庸置疑。

那麼，QA 活動呢？例如製作測試案例（這裡假設的是一般 QA 工程師會做的那種測試案例，例如整合測試）。如果把規格書交給 LLM，它能產出足以讓開發者驚覺「啊，這個觀點漏掉了」等級的測試案例嗎？像那種親身經歷過無數事故、平常也會使用產品因此對功能非常熟悉、並且橫向掌握各團隊正在推進的開發案件的 QA 工程師所做的測試設計，AI 有辦法取代嗎？……以我的實際感受來說，我覺得還是很困難。

如果只是限定在「製作封閉於規格書內容之內的測試」這種任務，其實已經可以被取代了。這點和程式撰寫者的情況並沒有不同。不過，對 coding 來說，只要「整個 repository 都丟給它」，更進一步說，只要「在 checkout 出來的 repository 目錄裡啟動 Claude Code」，就能把大量脈絡交給 LLM（至於它實際會不會讀是另一回事，至少它有得讀）；相對地，一旦換成測試案例製作，立刻就只剩下「一頁規格書」的程度。也就是說，對我們來說幾乎不需特別意識就能提供的脈絡大小，在 coding 與測試案例製作之間存在很大的差距。

上面雖然舉的是測試案例製作，但其實規格書 review、設計討論、缺陷管理等各種場景，這個脈絡都會發揮作用。畢竟如果沒有產品特有的脈絡，無論是施策規劃還是資料分析，都會變成在沒有前提知識的情況下硬碰硬，效率自然很差，也無法發揮預期的效能。

要和 AI 打交道，就必須彌平 coding 與非 coding 任務之間的這道差距。

規格在哪裡

既然已經知道要把大量脈絡交給 LLM，那麼接下來就要思考怎麼交。所謂脈絡，其實大致上需要幾種類型，例如既有規格、改修內容、過去的事故資訊等。沒有人會在不提供改修內容的情況下就要求 AI 產生測試案例吧。事故資訊很久以前就已經是透過 ticket 管理系統來管理，所以透過 MCP 串接之類的方法應該就能解決。那麼，既有規格要怎麼辦呢？我想到兩種做法。

①把至今為止做過的所有規格書都交出去

比起只有一頁規格書，這當然好得多。至少可以取得這次專案範圍之外的規格。不過，和程式不同，作成於一年前的規格書大概已經幫不上忙了。以那份規格書為輸入寫出的程式，很高機率早就被改過了，而且規格書本身大概也沒有持續維護。換句話說，裡面會混入謊言，因此對產出的測試案例也必須全部抱持懷疑，最後人類的 review 工時恐怕會變得非常可觀。

我也曾想過，把所有規格書累積起來就會變成現在的規格；但以我們公司而言，現實上並不會如此。畢竟不寫規格就直接改程式是家常便飯。另外，和 bug 不同，規格書往往沒有統一的寫法與固定存放位置，所以光是把所有內容蒐集齊全本身就很困難。

②把所有程式碼都交出去

這也不差。和規格書不同，程式碼的全部內容理所當然應該都能在立即可存取的地方取得，而且最重要的是，程式碼不會說謊。不過，程式碼只能告訴你「目前會怎麼運作」。而測試是要根據「希望它怎麼運作」，也就是規格與需求來設計才有意義。要確認需求的功能是否完整且正確地落實到程式碼中，只有程式碼是絕對不夠的。

來做規格 DB 吧

這次我採取的做法就是這個。我把描述規格的短句——公司內部稱為 user journey——大量蒐集起來，並以可搜尋的形式（放到 Notion DB 裡）保存。

「咦，你剛才不是才說『規格書不會被維護』嗎？」大概會有人這樣吐槽吧。但重點就在這裡：我一開始就只做成可維護的粒度。當規格有變更時，我們 QA 工程師會手動把變更反映進去。

舉個例子，像是「已付費的使用者可以對付費文章留言」、「未付費的使用者無法在背景播放影片」這樣的粒度。我們不會涵蓋細微的畫面規格，也不會涵蓋複雜條件的組合。

如果規格有變更，我們就會透過定期檢查 release note，或在執行受託測試的過程中將其撈出來2，然後把它改寫成例如「未付費的使用者也可以在背景播放影片」之類的規格。

把規格 DB 當作脈絡交出去

接下來只要把這個規格 DB 交給 LLM，它就能相當不錯地幫忙做規格書 review 或產生測試案例了。例如指出規格書裡沒寫到的既有功能迴歸風險，或產出與過去發生過的事故相關的測試案例。

一開始我原本以為，只是單純把 user journey 拼湊起來的資料庫，應該不會運作得很好。可能還需要加上標籤、結構化、另外寫出前提知識等等，這些都到位後，才會對 review 等精度提升有幫助。

然而，僅僅是透過 MCP 把彼此零散的 user journey 拼湊型資料庫串起來，它就已經能相當正常地運作。LLM 會根據任務目的，自行以自然語言搜尋規格 DB，並一邊整理、比較搜尋結果，一邊建立執行任務所需的知識。前陣子這樣還行不通，我也曾用同一個 DB 實作 RAG，但最近看起來光是提供 DB 存取權限，它就會自己善加運用。AI 的進化真可怕。

至於技術細節講起來會很長，這裡就不展開了；簡單說，我們是用 Notion MCP 串接，並做了避免超過 rate limit 的調整，也盡量讓它一次就完成搜尋。雖然偶爾還是會失敗，但大致上運作良好。不過我對速度還不滿意，所以目前正在進一步加速中（之後有機會再另外說）。

在 NewsPicks，我們把這做成 Claude 的外掛，並在公司內部的 Marketplace 中發佈。不過光是發佈出去大家不一定會用，所以我也在公司內部四處推廣，正一點一滴地增加使用者。

關於維護

前面提到這個規格 DB 只會以可維護的粒度來建立，但這其實是以 AI 導入前的世界為前提所做的設計。嚴格說來，這個規格 DB 本身並不是為了餵給 AI 而設計與建置的，而是我從 2022 年左右開始，為了讓人類自己使用而做的東西（テストカバレッジはテストの家計簿だよねって話）。如果是現在，應該可以更好地運用 AI 來進行維護，所以最近我也在嘗試用 AI 做自律式的規格 DB 維護。等之後有更多成果，我會再寫成文章分享。