人工智慧的限制：它無法自我評估其輸出結果。

人工智慧正在迅速改變軟體的設計、編寫和測試方式。開發團隊現在可以利用人工智慧產生程式碼、創建測試案例、識別潛在缺陷，並自動執行重複性的品質保證（QA）任務，而這些速度在幾年前似乎還難以想像。

這種速度很有價值，但同時也為品質保證帶來了新的問題。

當同一種技術用於軟體的創建和驗證時，組織可能會陷入互不信任的惡性循環。例如，人工智慧模型可能基於對需求的特定解讀產生程式碼，然後又基於相同的解讀產生測試案例。如果最初的假設是錯誤的，那麼程式碼和測試案例雖然看似一致，卻無法滿足使用者的需求。

換句話說，人工智慧無法獨自評判自身的表現。因此，完全依賴它是極其不明智的。

這並非反對人工智慧輔助開發。錯誤、故障和輸出不一致是仍在發展中的技術的必然特徵。我自己也親身經歷過這些錯誤和故障的表現。關鍵問題在於，企業是否擁有自主機制來偵測這些故障，以免影響顧客、員工或關鍵業務流程。

共同的假設會造成共同的盲點。

傳統的軟體品質保證流程已經認識到開發與測試分離的價值。系統開發者對系統有著深入的了解，但這種熟悉感反而會讓他們難以質疑系統建構所基於的假設。而獨立的測試人員則從不同的角度審視同一個系統，他們不僅關注程式應該實現的功能，還會考慮程式出錯的可能性。

同樣的原理也適用於人工智慧。

使用相似資料訓練、接受相同需求或在相同開發環境下運行的模型，可能會重現相同的盲點。例如，一個模型在產生某個特徵時，可能會忽略模糊的需求、不尋常的使用者路徑或裝置特有的極端情況。而另一個負責測試該特徵的模型，則可能強化這種疏漏，而不是發現它。

如果僅僅因為人工智慧產生的測試運行成功就將其視為品質的證明，那就尤其危險了。成功的測試僅僅證實了測試條件得到了滿足，但並不能證明這些條件是完整、獨立或有意義的。

其結果可能是技術上一致但實際應用上存在缺陷的系統。

生成式人工智慧與形式化軟體品質保證之間的根本矛盾在於可重複性。現代人工智慧程式設計代理旨在生成和適應。也就是說，即使目標看似相同，它們也可能選擇不同的步驟、使用不同的工具、以不同的方式解讀上下文，並產生不完全相同的程式碼或測試。

這並非總是由於系統在每次運行過程中學習；機率生成、上下文變化和模型演化也是造成這種差異的原因。這種變異性在團隊探索解決方案時可能非常有用，但它違反了品質保證 (QA) 的一項基本原則。也就是說，受控測試應該在相同版本、相同條件下進行，並具有明確的預期結果以及成功或失敗的證據，且結果應可複現。

如果沒有這種控制，組織可能只有人工智慧活動，而沒有真正的保證，而且輸出結果看起來合理，但無法可靠地複製、衡量、審計或辯護。

職業成功並非用戶成功。

許多自動化測試透過程式碼級訊號來評估軟體。它們會檢查服務是否會傳回預期回應，頁面是否包含特定元素，或者是否可以透過識別碼或選擇器定位按鈕。

這些測試固然重要，但它們與驗證使用者體驗並不相同。例如，測試可能只是確認某個按鈕的存在，即使它被其他元素遮擋；也可能只是確認某個字段包含文本，而沒有意識到文本已被截斷、顯示位置錯誤或格式混亂，導致無法閱讀。

測試可能會發現一個技術上存在但在較小螢幕上無法存取的清單。它也可能確認交易已完成，卻忽略了向使用者顯示的確認訊息中包含錯誤的金額、帳戶或狀態。

從系統角度來看，軟體運作可能正常；但從使用者角度來看，它卻出了故障。

這種區別很重要，因為現代數位服務越來越依賴應用程式程式碼、瀏覽器行為、作業系統、螢幕尺寸、遠端桌面、虛擬環境和第三方元件的複雜組合。

對這些圖層的任何變更都可能會改變螢幕上顯示的內容，但這並不一定會導致傳統的功能測試失敗。因此，測試不僅應該檢查平台報告的內容，還應該檢查使用者實際看到的內容和可以執行的操作。

為什麼視覺驗證很重要？

對使用者介面進行視覺驗證提供了一個獨立的視角，因為它測試的是顯示給使用者的結果，而不是僅僅依賴應用程式的內部結構。

這種獨立性至關重要。基於程式碼的測試通常依賴對被測系統的了解，例如物件識別碼、文件結構、輔助功能標籤、API 或預期資料回應。而視覺驗證則可以評估最終呈現給使用者的介面，包括佈局、定位、內容、狀態以及在不同環境下的可用性。

視覺驗證並非軟體品質保證中的一個獨立階段，也不能取代功能測試、整合測試、安全測試或效能測試。相反，它貫穿所有品質保證部門，無論使用者介面是在設計、建置、修改或測試過程中出現，從單一元件和單元級檢查，到整合測試和系統測試，再到使用者驗收測試，都離不開視覺驗證。

功能測試確認流程已正確完成；視覺驗證確認結果呈現準確一致，且始終可用。可靠的品質保證需要在整個開發生命週期中貫穿這兩者。

隨著人工智慧產生的軟體變更比例不斷增長，這種需求變得日益明顯。人工智慧工具可以快速產生程式碼，但這種速度也增加了品質團隊必須評估的變更數量和頻率。如果沒有專注於使用者體驗的保障層，缺陷可能會在交付鏈中迅速洩露，而組織卻難以察覺。

視覺驗證可以起到保障作用，彌合科技實現與人類經驗之間的差距。

迭代性將自動化轉化為可靠的指南

人工智慧能夠有效地產生創意、腳本和潛在的測試場景。然而，其輸出結果在連續運行中可能會有所不同。模型可能會根據上下文、配置或機率變化對相同的指令做出不同的解釋。這種靈活性在探索階段可能很有用，但不足以確保測試結果的正式品質。

用於批准軟體發布的測試必須具有可複現性。相同的輸入應導致相同的操作、相同的檢查點和相同的通過/失敗標準。團隊必須能夠明確指出測試內容、測試時間、涉及的應用程式版本以及接受測試結果的原因。

人工智慧能夠有效地產生創意、腳本和潛在的測試場景，但生成式和智慧體系統本質上並非確定性的。由於機率產生、命令和上下文變化、模型更新、檢索結果以及智能體在選擇工具和規劃下一步行動時的決策等因素，它們的輸出可能會有所不同。對於軟體開發而言，這種靈活性可以加速探索過程。然而，對於正式的品質保證而言，它卻帶來了一個根本性的控制問題。

用於批准軟體發布的測試必須具有可複現性和可驗證性。相同的應用程式版本、輸入和環境應產生相同的既定流程、檢查點和成功標準，使團隊能夠準確地確定測試內容、測試時間、涉及的版本以及結果被接受的原因。

只有這樣才能衡量成功和失敗隨時間的變化，重現缺陷，並在審計或結構化環境中依賴證據。

這就是利用人工智慧加速測試創建和任其成為測試領域事實上的權威之間的區別。了解何時應該停止完全依賴人工智慧至關重要。

人工智慧可以幫助團隊設計測試案例、識別缺陷，並減少自動化日常工作流程所需的工作量。然而，一旦測試被納入品質保證流程，就必須對其進行控制，確保其結果明確、結果具體、可追溯且可審計。預期結果必須清晰明確。變更必須經過審查。失敗必須可復現。成功和失敗的證據都必須保留。

如果沒有這些控制措施，組織可能知道人工智慧系統執行了“一些測試”，但卻無法確切證明發生了什麼。這會削弱營運信任的基礎，更會削弱問責的基礎。

受監管的環境會增加風險

介面錯誤造成的後果並非均勻分佈。

在消費者應用中，不一致的欄位或錯誤的提示訊息會導致使用者沮喪並造成收入損失。在金融、醫療、國防或政府等領域，類似的缺陷可能會影響支付流程、臨床決策、操作指南或公共服務。顯示錯誤狀態、隱藏警告或呈現過時資訊的介面，其後果可能遠遠超出螢幕本身。

監管機構還必須能夠解釋其管控措施並提供有效性的證據。僅僅聲稱某個系統已經過測試是不夠的。這些機構可能需要證明測試的一致性、結果的審查以及軟體在部署環境中的運作符合預期。彌合這種透明度差距對於實現這一目標至關重要。

人工智慧提供的保證因運作情況而異，這使得這項任務更加困難。同樣，那些只專注於內部系統回應而忽略員工或客戶最終使用者介面的測試策略也存在同樣的問題。

獨立且可重複的視覺驗證有助於提供更清晰的證據鏈。它不僅表明應用程式返回了預期數據，還表明在需要人工決策或操作時，正確的資訊以可用的格式出現在正確的位置。

這一點至關重要，尤其是一些看似微小的顯示錯誤可能會影響使用者行為。隱藏的警告、錯位的小數點、錯誤的計量單位或過時的狀態指示器或許不會阻止應用程式運行，但仍可能誘使用戶採取錯誤的操作。

在這些環境中，介面不僅僅是裝飾層；它是運行控制系統的組成部分。

速度與控制的結合

最佳方法不在於在人工智慧和既定的品質實踐之間做出選擇，而是為二者分配最合適的角色。

人工智慧可以加速開發、擴大測試覆蓋範圍，並減少自動化生產所需的人工工作量。獨立驗證可以挑戰這些輸出結果背後的假設。確定性測試可以將人工智慧產生的有用見解轉化為可重複的控制措施。可視化檢查可以確認技術上成功的軟體也能有效地為使用者服務。

這種分層模型使組織能夠利用人工智慧，而不會將生產力與證明力混淆。

該模型也認識到，沒有任何單一的測試方法可以提供完全的保證。程式碼級測試可以驗證各個元件的行為。

整合測試可以確定係統之間是否通訊正常。安全測試可以發現漏洞。性能測試可以檢驗系統在壓力下的運作。在使用者介面開發的各個階段進行視覺驗證，可以確定最終結果是否準確、易於存取和使用。

其價值在於將這些方法結合起來，而不是要求一種方法取代所有其他方法。

隨著人工智慧與軟體交付的融合日益加深，品質保證必須變得更加獨立，而非削弱。企業應假定人工智慧產生的軟體可能存在意料之外的缺陷、不完整或不一致之處。我們的目標並非在軟體創建之初就消除所有錯誤，而是確保這些缺陷在交付給用戶之前就被發現，從而有助於彌合可能為人工智慧程式碼帶來風險的可見性差距。

人工智慧可以輔助完成作業，甚至提供批改建議。但最終成績必須來自獨立、可重複且負責任的評估流程。