Amazon Nova ActのQA Studioを並列実行とCI/CDへ拡張

AWSは、Amazon Nova Actを使うQA Studioへテストスイートの並列実行とCLIを加え、対話的な試験作成からCI/CDでの継続実行まで広げる実装を紹介しました。

要点

• テストスイートを複数のECS Fargate workerへ配り、ブラウザー試験を並列実行します。
• 集約画面で成功・失敗、ログ、スクリーンショットなどの成果物を確認します。
• OAuthのクライアント認証情報でCLIを認証し、終了コードと構造化出力をCI/CDへ返します。
• qa-studio runでbase URL、変数、リージョン、モデルなどを上書きできます。

今回のブログ記事で語られていること

第2部の記事は、QA Studioで作成したNova Actのブラウザー試験を、個人の画面操作からチームのリリース工程へ移す方法を扱います。テストスイートを実行すると、各ケースがECS Fargateのワーカーへ分配され、独立したブラウザー環境で並列に動きます。完了後は状態、ログ、スクリーンショットなどをまとめ、どこで期待した画面遷移から外れたかを確認できます。直列実行より待ち時間を短くしつつ、テストごとの環境を分離できる構成です。

CLIはOAuthのクライアント資格情報で認証し、qa-studio runから既存スイートを起動します。終了コードと構造化された結果を返すため、Pull Requestやデプロイ前のジョブへ組み込み、失敗時に工程を止められます。base URL、変数、AWSリージョン、利用モデルを実行時に上書きできるため、同じ試験をステージングと本番前環境で再利用できます。ただし、上書き項目が多いほど再現性を失いやすいので、実行した設定、アプリケーション版、モデル版を成果物へ残す必要があります。

AIが画面を見て操作する試験は、CSSセレクターへ強く依存する試験よりUI変更へ追随しやすい一方、確率的な判断と外部サービスの状態に影響されます。1回の失敗を即座に製品欠陥とせず、同じ条件での再現、スクリーンショット、操作履歴を確認します。並列数を上げると、テスト対象への負荷、テストデータの競合、外部APIのレート制限も増えます。各ケースに固有データを割り当て、終了時の後片付け、最大並列数、失敗時の再試行回数を定めることが重要です。

また、失敗した試験を自動で何度もやり直すと、不安定な欠陥を隠したり、対象環境へ同じ操作を重ねたりします。初回結果と再試行結果を分け、一定回数を超えたら人へ通知し、スクリーンショットと実行設定を一緒に保存する運用が必要です。

今回のブログ記事が関係する人

WebアプリケーションのQA担当、CI/CDを管理する開発基盤チーム、AIによるブラウザー試験の再現性と費用を評価する開発者に関係します。

結局、今回のブログ記事をどう読むべきか

試験生成より、並列実行、認証、終了コード、証跡によってリリース工程へ接続した点が中心です。最初は重要な利用経路に絞り、人による試験との差、誤検知率、実行時間、テスト対象への負荷を測ってください。