Amazon Nova Act 測試與 Playwright 並行，成為 Epsilon 的共享服務

Epsilon 已將 Amazon Nova Act 測試納入共享服務，同時保留其原有的瀏覽器自動化框架 Playwright，作為迴歸測試的核心支柱。此部署結合以自然語言撰寫的測試指令，以及由 AWS 管理的瀏覽器。其重要性在於產品團隊如何使用測試能力，而非全面取代已編寫的測試檢查。

AWS 於 10 月 29 日發表的案例研究描述了一項多租戶服務，即一個為團隊提供服務、並設有獨立存取界線的共享平台。Epsilon 的 Agentic Platform 團隊負責整合工作。產品團隊可使用此能力，而毋須自行營運瀏覽器基礎設施。這令核心問題從代理能否瀏覽網頁，轉為由誰負責圍繞它的服務。

有用的比較是共享測試基礎設施，對比各產品團隊重複進行的工作。Playwright 仍是這個圖景的一部分。對工程領導者而言，這項部署提出了一個實際問題：有多少測試工作應留在各應用程式團隊內部，又有多少應成為平台責任？

Amazon Nova Act 測試納入平台

Epsilon 的部署將瀏覽器測試視為可重用的組織能力，而非每個團隊都必須自行營運的另一項工具。

根據這份意圖驅動測試案例研究，團隊會透過共用介面提交工作流程。Nova Act 負責解讀指令，而 Amazon Bedrock AgentCore Browser 則提供瀏覽器環境。Epsilon 的周邊平台負責執行與結果處理。

這個分別很重要，因為瀏覽器互動只是可用測試服務的一部分。還必須有人決定誰可以執行測試、可存取哪些應用程式，以及證據應存放在哪裏。當多個團隊共用同一項能力時，這些決定就更加重要。

瀏覽器示範通常令操作一目了然：代理開啟網頁、填寫表格，並到達目的地。內部服務亦必須令責任歸屬同樣清晰。當執行失敗時，用戶需要知道問題由應用程式、指令還是平台造成。

對產品團隊而言，這種分工改變了採用決策。當瀏覽器操作已有明確負責人時，評估一項測試能力會較容易。團隊可以專注判斷測試是否描述有意義的產品行為，以及所得證據能否支持發佈決策。

不過，對平台團隊而言，責任會隨之擴大。共享服務需要就執行、存取、失敗報告和支援訂立清晰合約。從應用程式團隊移除基礎設施工作，等同將該工作轉移至集中式營運模式。

這項轉移值得關注，因為它決定此方法能否在組織層面擴展。對建立者有效的能力，未必同樣容易支援彼此無關的應用程式。不同的驗證流程、發佈節奏和測試環境，會帶來不同期望。

設想一個示例內部應用程式更改了其開戶畫面。應用程式團隊希望在重新設計後，驗證同一項業務結果。平台服務應協助分辨無害的版面變動，以及實際未能完成開戶的問題。

這種分辨不只需要找到另一個可點擊元素。服務必須對預期結果有穩定理解，並附有顯示實際發生情況的證據。否則，適應能力可能變成接受不同結果的許可。

因此，這則新聞涉及更廣泛的責任界線。應用程式團隊繼續負責產品正確性；平台則負責讓瀏覽器執行可供使用並可供檢視。明確保留這些責任，有助評估這種安排。

在這裏，Amazon Nova Act 測試最有意思之處，在於它作為額外的服務層。其價值取決於團隊能否取得有用覆蓋範圍，而毋須承擔另一套要維護的系統。

產品團隊獲得存取權，平台團隊則承擔問責

集中化只有在共享服務為團隊提供從請求到證據的可靠途徑時，才能減少重複工作。

壓力落在平台工程領導者身上，不下於測試工程師。一旦瀏覽器測試透過共用介面提供，用戶便會期望行為一致；當介面不再產生可用結果時，他們亦會期望有人回應。

這改變了基礎設施開銷的含義。產品團隊或可免於管理瀏覽器程序，但仍需要測試帳戶、合適資料及清晰的驗收準則。基礎設施從其工作清單中消失，但測試責任依然存在。

一條有用的組織界線，是將執行責任與情境責任分開。平台負責運行工作流程的機制；應用程式團隊負責工作流程應證明甚麼。任何一方都無法完全取代另一方。

缺少這條界線時，集中式服務可能累積無法解決的請求。平台工程師或可診斷工作階段故障，卻欠缺產品知識去判斷意外的確認訊息；應用程式工程師可能明白該訊息，卻無法取得執行細節。

因此，服務需要支援圍繞失敗情況的協作。報告應協助兩個群組辨認相關的應用程式狀態，以及正在評估的指令。若結果看來可疑，單憑綠色指示燈無法向任何一方提供足夠資訊。

產品經理與品質主管亦可能擔當角色。以自然語言撰寫的指令，令跨職能討論建議情境更容易。然而，參與者增加亦提升審閱的重要性，因為易讀的語言仍可能描述不完整的測試。

例如，一項示例指令可能要求代理確認新建立的記錄已出現。但這留下數個未解問題：哪一筆記錄應出現、應在哪個帳戶下出現，以及應包含哪些已儲存的值？

這些細節界定正確性。平台可以標準化指令的運行方式，但產品團隊必須提供預期行為。令撰寫工作更易參與，應增加參與度，而非削弱對精確期望的責任。

這亦涉及知識管理問題。團隊需要保留情境存在的原因、促成它的事故，以及其後修訂期間的變更。否則，易讀的工作流程可能成為另一批沒有說明的產物。

正在評估此模式的工程團隊，應把測試證據與既有文件實務連結。一個可搜尋知識庫可協助保留情境理據，以及技術決策和故障調查紀錄。

這項組織機會比消除測試工作更有限：它移除重複的營運設定，讓團隊能把更多注意力放在產品行為上。這能否實現，取決於支援品質及共享介面的實用性。

這令採用成為服務設計問題。平台領導者應評估團隊能否理解結果及解決故障，而非只透過建立工作流程來衡量成功。

受管理瀏覽器將執行與應用程式責任分開

此架構把決定要做甚麼，與提供瀏覽器操作環境這兩件事分開。

在 Epsilon 的部署中，Nova Act 提供解讀層。AgentCore Browser 提供遠端瀏覽器，即運行在用戶本機以外的瀏覽器。周邊服務則把這些能力連接至組織存取控制和報告機制。

AWS 在其文件中將受管理瀏覽器工作階段描述為具備自動化連線及互動式檢視功能的隔離環境。文件亦列明 Nova Act 和 Playwright 為支援的互動程式庫。因此，受管理瀏覽器基礎設施不要求只選擇一種測試方法。

這種分離具有策略價值。組織可以獨立評估瀏覽器服務，以及驅動它的指令。基礎設施適用性和測試品質仍是相關決策，但不應把任何一項視為另一項的證明。

受管理環境可以簡化瀏覽器營運，但規格不佳的工作流程仍會產生薄弱證據。相反，精心設計的測試在執行環境不可靠時，仍可能難以使用。可信的服務必須同時處理兩者。

瀏覽器界線亦令安全問題更清晰。隔離工作階段限制一類風險，但不決定應用程式帳戶可做甚麼。目標應用程式內的權限，仍主宰瀏覽器操作的後果。

設想一個可編輯客戶記錄的假設測試帳戶。將其瀏覽器移至受管理環境，並不會令這些編輯變得無害。該帳戶仍需要與所檢視環境及情境相稱的權限。

同樣的推理適用於網絡存取。瀏覽器服務必須能連接目標應用程式，但可達性應遵循審慎政策。開戶期間的便利，不應悄然變成對無關內部系統的無限制存取。

這些是評估要求，而非對 Epsilon 部署的指控。此案例說明，基礎設施責任與應用程式授權應納入同一架構討論。採用類似模式的團隊應詢問這些界線如何互相影響。

證據收集引入另一條界線。瀏覽器產物可能包含測試帳戶可見的資訊。因此，即使底層工作流程在暫時性工作階段中運行，錄影存取權亦應有獨立控制措施。

AWS 透過即時檢視、錄製、重播及營運指標，描述瀏覽器可觀測性。可用性需要留意設定：其瀏覽器文件指出，工作階段錄製屬於自訂瀏覽器能力。

這項限定在評估內建可見性聲稱時十分重要。已記載的功能，不等於已啟用、已保留並受到適當限制的產物。買方應檢視已部署的設定，而非假設每項能力都會自動適用。

對 Amazon Nova Act 測試而言，這形成清晰的架構檢驗。共享服務應令執行更容易，同時保留圍繞權限、證據及責任的可理解界線。受管理基礎設施有助達成這個結果；組織政策則令它完整。

將 Nova Act 與 Playwright 對立，是不完整的框架

有意義的選擇在於，應在哪些地方讓解讀發揮作用，以及在哪些地方應保留明確檢查作為權威。

將討論框定為 Nova Act 與 Playwright 的對決，可能會忽略這次部署的核心啟示：共享平台可以提供不止一種執行方式。團隊毋須讓每個情境都依賴同一種互動模式。

Playwright 也值得獲得公平的技術比較。其具韌性的定位器指引建議透過面向使用者的屬性與明確契約識別元素，並不鼓勵不必要地依賴頁面結構和樣式細節。

定位器是用於識別頁面元素的規則。根據按鈕的角色和名稱選擇定位器，與依賴其在巢狀容器中的位置並不相同。因此，腳本化測試包含會影響維護工作的設計選擇。

這使得「自然語言執行必然在韌性方面勝過腳本化測試」的說法變得更複雜。比較取決於腳本化基準採取甚麼做法，以及發生了甚麼變更。薄弱的基準，無法讓讀者了解維護良好的測試套件。

更有力的分析問題是，團隊目前在哪些地方投入了工夫，卻沒有獲得有用的確定性。有些情境需要細緻而穩定的檢查；另一些則涉及穿越介面，而其附帶的呈現方式比預期的業務行為更常改變。

詮釋層在後一類情境中具有吸引力，因為它可以描述目的地，而毋須以機械式方式指定每一次互動。但這種彈性需要界限。代理程式應在保留預期結果的同時調整路徑。

以帳戶管理測試為例，可將這個分別具體化。前往設定畫面或可容許選單位置改變；確認某項權限已被移除，則需要精確檢查最終狀態。

這些職責可以共存於同一套測試策略中。彈性的導覽可以通往明確的驗證。有效的架構會保留這種分別，而非把成功完成導覽視為正確性的充分證據。

Playwright 的自動重試斷言提供了相關背景。斷言是把實際行為與預期結果進行比較的檢查。Playwright 提供針對文字、值、可見性、URL 及其他條件的檢查。

當應用程式以非同步方式更新時，這種精確性仍然很有價值。測試應容許預期狀態在已界定的限制內出現；若所需條件始終未出現，亦應失敗。

自然語言工作流程同樣需要清楚界定何謂成功。「完成任務」可能留下發布閘門無法容忍的詮釋空間。團隊應先定義結果，再決定瀏覽器如何到達該結果。

當 Nova Act 與 Playwright 的討論植根於這些職責時，便會更有用。組織可針對特定情境比較維護工作、診斷清晰度及缺陷偵測能力。整體誰勝誰負不及把每種方法分配予其能可信驗證的工作重要。

Epsilon 決定保留其迴歸測試骨幹，支持這種審慎的解讀。該服務擴展可用的測試模式，並非證明現有迴歸測試實務已不再需要。

更快的撰寫速度不代表更佳的缺陷偵測

撰寫速度、成功執行，以及具意義的缺陷偵測，衡量的是不同事物。

Epsilon 報告指出，其內部量度的撰寫效率提升為四至六倍，而已儲存軌跡重播的通過率為百分之百。軌跡是已錄製的一連串瀏覽器操作。這些結果應維持為歸因於該公司的說法，結論亦應限於所報告的條件。

該刊物並未確立一個經獨立驗證、涵蓋任意應用程式的可靠性比率；亦未確立每次成功重播都能偵測產品團隊關心的缺陷。通過率描述的是某一特定評估流程下的結果。

分母很重要。當讀者知道哪些工作流程被納入重播集合、兩次執行之間有甚麼變更，以及失敗如何分類時，重播結果才更具資訊價值。沒有這些背景，標題中的百分比不能承載更廣泛的可靠性主張。

這並不代表所報告的結果毫無關聯。可重複執行是有用的；只是它回答的問題，比測試系統能否在變動條件下辨識錯誤行為更狹窄。

嚴謹的評估應刻意引入故障。設想一個假設的表單：它顯示成功訊息，卻沒有儲存已提交的記錄。只檢查訊息的測試可以通過，但業務操作其實失敗。

另一個例子涉及帳戶界限。某個工作流程可能成功找到屬於另一個帳戶的記錄。完成導覽並不能證明應用程式有強制執行預期的存取規則。

這些例子揭示任務完成與驗證之間的差異。瀏覽器代理程式自然會透過已完成的任務來評估，但測試需要能察覺錯誤結果。能抵達目的地的系統，在批准發布前仍需要額外證據。

適應能力帶來另一項取捨。若重新設計的介面提供替代路徑，採用該路徑可以保留有用的覆蓋範圍；若原本路徑本身就是必要行為，繞過它則可能掩蓋迴歸問題。

因此，團隊需要區分可容許的調整，與應令測試失敗的行為。這是產品決策，不應由執行引擎在沒有界限下自行推斷。清晰的預期可讓韌性與問責性兼容。

人工介入也需要明確處理。獲協助後完成的工作流程，所提供的證據與全程無人介入的執行不同。把兩種結果合併為未作區分的成功數字，會令營運規劃更困難。

重試亦然。經多次嘗試後最終通過的測試，所帶來的發布體驗與持續穩定通過的測試不同。評估應保留這種分別，而非將其壓平為最終的綠色狀態。

對 Amazon Nova Act 測試而言，最有力的證據應把撰寫工作與缺陷偵測及調查工作連結起來。當產生的情境仍具辨別力時，更快建立測試才有價值；若含糊的檢查日後帶來更多覆核工作，說服力便較低。

因此，懷疑立場其實很務實：要求證據證明該服務會因正確原因而失敗。當刻意引入的應用程式缺陷產生清晰、可採取行動的失敗結果時，成功執行便更具意義。

下一步證據應把採用情況與發布信心連結起來

下一階段應顯示，共享存取方式能否在持續變化的應用程式中提供有用覆蓋。

在未來數月，有三個訊號值得按次序留意：更廣泛的採用、變更下的行為，以及每項結果周邊的營運工作。這些是評估優先事項，並非 Epsilon 或 AWS 公布的里程碑。

首先，留意可區分工作流程建立與持續使用的採用證據。有用的問題是，更多產品團隊在初步導入後，會否繼續依賴這項服務。當團隊能說明它填補了哪些覆蓋缺口時，重複使用會更具說服力。

廣度同樣重要。熟悉應用程式內的數個工作流程，無法與跨越不同產品的持續使用建立相同的組織層面成果。證據應指出應用程式行為的多樣性，同時不披露機密實作細節。

若採用增長而毋須相應增加專屬支援，這個訊號將強化平台論點；若每個團隊都要經過大量自訂介入才能產生有用結果，該論點則會被削弱。

其次，留意測試在應用程式變更及刻意引入缺陷後的表現。外觀上的改動不應自動使具意義的測試失效；錯誤的業務行為仍應產生工程師能理解的失敗結果。

有說服力的評估會區分無害的介面變更與損壞的結果，亦會區分需要修訂的工作流程與平台執行失敗。這些類別決定團隊能否在積極開發期間信任該服務。

若測試能容忍呈現方式的變更，同時拒絕錯誤的應用程式狀態，這個訊號將增強信心；若調整掩蓋缺陷，或普通的重新設計需要大幅重寫指令，信心則會被削弱。

第三，留意完成測試周邊的完整營運負擔。撰寫只是開始。覆核、執行、重試、檢查證據及調查失敗，全都構成取得可信結果所需的工作。

最有力的比較會一併檢視這些活動。節省撰寫時間但增加含糊失敗的服務，與同時減少調查工作的服務，帶來的是不同取捨。團隊需要足夠細節，才能判斷哪種結果適用。

若更廣泛使用能產生可詮釋的結果，且支援要求可管理，這個訊號將強化論據；若表面上的自動化依賴頻繁的人手救援或難以覆核的產物，則會削弱論據。

對企業買家而言，這些訊號提供了比泛泛談論自主測試更具體的評估框架。對開發人員而言，它們讓焦點維持在發布信心；對平台團隊而言，它們可判斷集中化是否真正消除了重複工作。

這次部署的重要性，取決於這種組織層面的可能性。共享的瀏覽器執行方式可為產品團隊提供共同起點，同時讓不同測試方法保留各自不同的職責。值得關注的證據，是這些職責如何經受真實應用程式變更的考驗。

採用 Amazon Nova Act 測試前，請問哪一段尚未覆蓋的使用者旅程值得關注，以及甚麼證據能使其結果可信。選擇一個具清晰業務結果的情境，然後同時檢視成功執行與刻意破壞的版本。比較撰寫、覆核、執行及調查所需的工作量。在正確性有此要求之處保留明確檢查，並記錄每個界線由誰負責處理失敗。讓評估緊扣實際發布決策，而非平實英語指令的吸引力。目標是建立一項能擴展有用覆蓋範圍、同時讓工程師有更清晰理由信任或拒絕建置版本的測試服務。哪個缺失情境能為你的團隊提供最有力的證據？