讀這份報告之前，先知道三件事
SmartBear 在 2026 年 8 月發布了《The State of Software Quality and Testing 2026》，副標題是「AI 信心很高，證據跟不上」。這一句話已經把整份報告的論點說完了，剩下的二十頁都在用數字證明它。
報告調查了 1,436 位負責測試與品質的技術人員，一半是實務者（practitioner，49%），一半是高階主管（leader，51%）。受訪者全部來自 500 人以上、年營收 5,000 萬美元以上的企業，分布在軟體/SaaS、金融、電信、醫療、零售五個產業，主要在美國與英國。
在往下讀之前，有三件事要先放在心裡：
- 這不是「AI 普及率」調查，而是「已採用者」調查。 受訪條件之一是「組織已在開發中使用 AI」。所以報告裡每一個數字描述的都是已經上車的人，不是整個產業。
- 樣本是大型企業。 中小團隊、新創不在裡面。台灣多數軟體團隊的規模和這個樣本差距很大，引用時要留意。
- SmartBear 是測試工具廠商。 報告最後一頁直接推銷自家的 BearQ「自主測試」產品。這不代表數據造假，但「數據」和「詮釋」要分開看：數據的部分相當可信，結論的部分帶著廠商立場。
接下來我會先講報告的核心論點，再逐章拆解，最後列出幾個我認為該保留的質疑，以及這些數據對實務真正的意義。
核心論點：離程式碼越遠，越有信心
整份報告反覆出現同一個結構：離程式碼越遠的人，對 AI 越有信心；離程式碼越近的人，越懷疑。 報告用「盲目信任（blind trust）」這個詞貫穿全文。把主管和實務者的數字並排，落差一目了然：
| 項目 | 主管 | 實務者 |
|---|---|---|
| 對 AI 生成的程式碼「有很大或完全信心」 | 73% | 52% |
| 認為 AI 能可靠地抓到自己的錯誤 | 81% | 64% |
| 信任 AI 寫的測試多於人寫的測試 | 72% | 56% |
| 認為自家的 AI agent 已被充分審查 | 95% | 86% |
| 認為自主測試能幫助跟上 AI 的產碼量 | 89% | 77% |
| 說自家出貨過後來在正式環境失敗的 AI 程式碼 | 50% | 41% |
最後一列值得多看一眼：主管回報了更多失敗，卻同時擁有更高信心。報告的解讀是「看到越多 AI 失敗，反而越有信心」，形成「用量增加 → 看到失敗 → 更有信心」的循環。我覺得這個解讀偏樂觀。另一個同樣合理的解讀是：主管看到的失敗是彙整過的數字，實務者看到的是具體的事故和加班，兩邊對「失敗」的體感完全不同。
整份報告最有衝擊力的單一數據是這個：46% 的組織出貨過後來在正式環境失敗的 AI 程式碼；而在這些組織裡，69% 的人仍然對 AI 程式碼「有很大或完全信心」。 換句話說，失敗的經驗並沒有校正信心。
這和 DORA 的研究結果一致：AI 採用率越高，交付不穩定性上升近 10%。但不穩定沒有讓人踩煞車。報告說得很直白：團隊不把失敗當成「不該用 AI」的訊號，而是當成「需要更多能力去檢查它」的訊號。
七個月內，AI 寫碼的比例翻了一倍
65% 的受訪者說 AI 寫了或加速了至少 41% 的程式碼，31% 說超過 61%。測試那邊的數字幾乎一樣：65% 說 AI 生成或維護了至少 41% 的測試覆蓋。
速度最驚人的是美國的對照：同一個問題（AI 寫至少 41% 的程式碼），1 月的調查是 43%，8 月變成 69%。要注意的是，1 月和 8 月是兩次不同的調查、不同的樣本，不是同一群人的追蹤。趨勢方向可信，精確的數字不要太認真。
速度的代價也出現在數據裡。55% 的受訪者說過去 12 個月發生過「開發速度超過測試能力」導致的品質問題。這些問題落地之後長什麼樣子？前三名是：大量重工（54%）、事故或當機增加（46%）、延誤發布（41%）。營收損失排很後面（18%），這很合理：損失的是先被人吸收掉的，是加班和重做，不是直接的帳面數字。
誰來驗證 AI？
這是整份報告最有實務價值的一章，可以拆成三個層次。
AI 自己測自己寫的程式碼，可以嗎？
只有 25% 的受訪者認為「永遠可以」。48% 認為「只有在人類監督下可以」，18% 認為「只限低風險程式碼」，7% 認為永遠不行。把後三者加起來，73% 的人不接受「同一個 AI 又寫又測」作為唯一機制。 實際行為也對得上：只有 3% 的團隊完全依賴 AI 自我驗證，84% 至少用一種形式的人工審查來驗證 AI 生成的測試。
54% 的團隊，讓 AI 從沒有人檢查過的指令生成程式碼
這是整份報告裡我認為最被低估的一個數字。報告自己也問了一句很尖銳的話：如果連 AI 是針對什麼規格在寫程式都不知道，要怎麼驗證它寫得對不對？
問題不在測試，而在上游。如果沒有人確認過 spec 反映的是真正的意圖，後面測試再多也只是在驗證錯的東西。報告的說法是：同一個系統既負責生成又負責驗證，結果是一個「測試黑盒子」——測試背後的邏輯、測試裡埋的假設，對名義上監督流程的人來說都是不透明的。你看到一整排綠燈，卻無法分辨那是真正的覆蓋，還是 AI 在確認自己的作業。
檢查點越晚越多，和 shift-left 背道而馳
報告問了三個時間點的獨立檢查比例：
- 生成前：46% 的團隊會先檢查 spec 是否反映意圖
- 提交前：49% 會獨立審查超過 60% 的 AI 程式碼
- 發布前：60% 會獨立測試超過 60% 的 AI 程式碼
數字一路往後遞增。團隊把驗證的力氣放在最靠近出貨的地方，而那正是修復成本最高的地方。我們講了十幾年的 shift-left，在 AI 生成程式碼這件事上，實務是反過來的。報告的結論很乾脆：AI 幫一些團隊提高了覆蓋，但沒有解決成本問題，因為抓到問題的時間點太晚。
能辨識，不等於能解釋
80% 的受訪者說他們能辨識出程式庫裡「全部或大部分」的 AI 程式碼。聽起來治理得不錯，但下一個數字就把它打回原形：47% 的團隊曾經無法解釋 AI 如何導致某個 bug 或正式環境事故。在已經出貨過失敗程式碼的團隊裡，這個比例是 73%。
更有意思的是，完整的稽核追蹤沒有幫助。有完整追蹤的團隊，72% 說不清楚 AI 在事故裡扮演的角色；沒有追蹤的團隊是 75%。幾乎一樣。這點很值得深思：記錄「哪些是 AI 寫的」和理解「AI 為什麼這樣寫」是兩回事。追蹤解決的是前者，是合規問題；它解決不了理解問題。
報告用傳統自動化測試做對比：以前一個測試失敗，會直接指向出錯的那段程式碼；現在 AI 生成的失敗，團隊是「盲目地」在調查。找 bug 的成本就是這樣爬上去的。
那麼出事的時候誰負責？42% 說是團隊或 team lead，29% 說是寫下或接受那段程式碼的開發者，19% 說是整個組織。只有 6% 認為 AI 工具廠商該負責。責任仍然完全落在人身上，而且落在離程式碼最近的那些人身上。這也是為什麼主管和實務者的信心落差不只是認知問題：當主管認為 AI 沒問題，而實務者知道有問題，補洞的壓力會全部落在實務者身上，而且往往沒有對應的工具和時間。
AI agent 跑得比監督快
96% 的組織在使用或評估 AI agent，43% 已經讓 agent 跑在開發、測試和正式環境三個地方。agent 從試點到正式環境的速度，比監督機制建立的速度快很多。
監督到底有多薄？只有 25% 的團隊在使用或合併前，由人類審查超過 80% 的 agent 產出。44% 的團隊，人類審查的比例在 60% 以下。但同時，95% 的主管說自家的 agent「已被充分審查」。報告稱之為「對不存在的治理的盲目信任」，並反問：組織知不知道真正的治理長什麼樣子？
審查有沒有用？有，但有限。審查超過 60% agent 產出的團隊，49% 出過失敗；審查 60% 以下的團隊，58% 出過失敗。差 9 個百分點。審查確實降低機率，但離「關上」風險還很遠。報告的結論是：審查是必要的，但要搭配獨立的測試與驗證。
治理工具的部分更鬆散：只有 34% 用專門的商業工具來治理 agent，其餘是自建護欄、個案處理，或者根本沒有正式監督。報告把「agent 治理」列為改善空間最大的領域。
自主測試是解方？報告沒點破的矛盾
報告的最後一章轉向解方。63% 的團隊說測試能力跟得上 AI 的產碼量，36% 說開始或已經跟不上。83% 認為「自主測試」（AI agent 自己生成、執行、調整、回報測試，人類只審查它標記出來的東西）能幫助他們跟上。採用的最大障礙不是成本（12%），而是「對結果的信任」（23%）。
這一章有一個報告自己沒有點破的矛盾。報告比較了「跟得上」和「跟不上」的團隊在部署階段的做法，其中一列是「更依賴 AI 驗證自己的產出」：跟得上的團隊有 45% 這樣做，跟不上的團隊是 37%。
也就是說，報告前面花了整整一章論證「AI 自己驗證自己是黑盒子」，後面卻把「更依賴 AI 自我驗證」的團隊算進「跟得上」的成功組。所謂跟得上，有相當比例是用更薄的驗證換來的。
英國的區域數據把這點講得更直白：73% 的英國團隊說跟得上，但其中 63% 承認為了跟上而做了至少一項取捨——減少審查、縮小覆蓋、延後發布，或者明知風險更高仍然接受。「跟得上」這三個字，需要配上「用什麼換的」一起看。
產業差異：跑最快的，摔最重
報告附錄的產業比較，把「信心與證據脫節」推到了極端。
| 產業 | AI 寫碼比例 | 出貨過失敗的 AI 程式碼 | 對 AI 程式碼有信心 | 無法解釋 AI 如何造成事故 |
|---|---|---|---|---|
| 電信與媒體 | 80% | 68% | 73% | 68% |
| 零售與電商 | 68% | 47% | 65% | 47% |
| 金融 | 62% | 46% | 61% | 45% |
| 軟體與 SaaS | 62% | 39% | 59% | 41% |
| 醫療 | 58% | 32% | 59% | 40% |
電信與媒體是最極端的樣本：AI 採用最高、失敗最多、最說不清楚事故原因，同時也最有信心。他們縮小測試覆蓋和減少審查的比例也是所有產業最高（各 30%），卻只有 50% 說測試跟得上，全產業最低。跑得最快，也摔得最重。
醫療剛好相反：採用最低、失敗最少，而「測試跟得上」的比例卻是最高的 69%。慢一點，反而比較穩。
金融是最懷疑 AI 的產業（19%），agent 採用也最低（42%）。但金融和醫療在「AI 產出的追蹤無法滿足合規或稽核要求」這一項上排前兩名（55% 和 57%），受管制的產業，合規壓力最大，而治理最跟不上。
五個該保留的質疑
數據很有力，但讀的時候有幾件事要放在心上。
- 所有數據都是自陳。 「我能辨識 80% 的 AI 程式碼」「我們的 agent 有被充分審查」都是受訪者的自我評估，報告自己也承認這些自評和實際狀況對不上。拿來證明「人們怎麼想」很好，拿來證明「實際狀況如何」要打折。
- 相關不等於因果。 「審查多的團隊失敗少」也可能是「成熟團隊既審查多又失敗少」。報告說治理方式對出貨結果有「可量測的影響」，這是過度推論。
- 解方和產品高度重合。 報告的結論是「自主測試，加上人類監督」，這剛好就是 BearQ 的定位。數據部分（信心落差、檢查時機偏晚、agent 監督不足）和廠商利益沒什麼關係，相當可信；但「自主測試是出路」是廠商的立場，不是數據自然導出的結論。同樣的數據，其實也支持「先把 spec 驗證往前移」「獨立審查」這類不需要買工具的做法。
- 「跟得上」的定義模糊。 如前所述，報告把靠降低驗證標準來跟上的團隊也算成功組。「63% 跟得上」這個數字需要配上「其中多少是用取捨換的」一起看。
- 沒有問最關鍵的問題：AI 寫的測試，有多少是在測對的東西？ 報告量了覆蓋率由 AI 生成的比例，量了對 AI 測試的信任度，但沒有任何數據碰觸「AI 生成的測試是否真的能抓到 bug」。這是整份報告最大的空白，也正好是「黑盒子」問題的核心。
結語：問題不在 AI 產碼太快
把廠商立場濾掉之後，這份報告的數據支持幾個相當明確的主張：
- 驗證的瓶頸已經從「寫測試的速度」移到「確認意圖的能力」。 54% 的團隊從沒人檢查的指令生成程式碼，這是上游問題，不是測試工具問題。
- 檢查點放錯位置是普遍現象。 多數團隊把獨立驗證集中在發布前，生成前的 spec 檢查只有 46%。這剛好反了。
- 「有被記錄」不等於「能被解釋」。 稽核追蹤解決合規問題，不解決理解問題。
- 審查有效，但效果有限。 審查是必要條件，不是充分條件，需要搭配獨立測試。
- 組織內部的信心落差本身就是風險。 主管信、實務者不信的時候，補洞的壓力會全部落在實務者身上。
如果只能從這份報告裡帶走三個數字，我會選這三個：
- 46% → 69%：出貨過失敗的 AI 程式碼，之後仍然對它有信心。失敗經驗沒有校正信心。
- 54%：讓 AI 從沒有人檢查過的指令生成程式碼。
- 46% / 49% / 60%：生成前、提交前、發布前的獨立檢查比例。驗證集中在最貴的階段。
這三個數字加起來講的是同一件事：問題不在 AI 產碼太快，而在沒有人確認過「要做什麼」，就開始驗證「做得對不對」。工具可以把測試跑得更快，但跑得再快，也追不上一個從一開始就寫錯的規格。
資料來源：SmartBear, The State of Software Quality and Testing 2026, 2026 年 8 月調查，N=1,436。
發佈留言