参考実装でテストをアプリへまとめ、役割ごとの操作とチーム間共有を管理します。失敗が不安定なテストを考慮した指標や実行記録を示しました。 自動テストの数だけでなく、所有者と修正責任を明確にする更新です。共有先の権限は本人の役割と付与した範囲の両方で制限します。 自動テストが増えた後の管理を扱う AWSは10月28日、Amazon Nova Actを使うQA Studioの参考実装について、組織規模での管理機能を紹介しました。自然言語のテスト作成と画面操作、前回のテスト群とCI連携に続く第3部です。今回はアプリ単位でテストをまとめ、その所有者とチームの権限を定めます。テストが増えると、作る速さだけでなく、誰が修正するか、全体がどれほど安定しているかが課題になります。記事はその段階の運用を対象にしています。利用者のAWSアカウントへ配備する参考実装であり、新しい独立した管理サービスとして一律提供されるという説明ではありません。既存のテストを組織で使い続ける仕組みの追加です。 不安定な結果と共有時の権限を見える形に テストとテスト群はアプリへ属し、結果はCloudWatchの指標としてアプリと環境ごとに記録します。成功率、実行数、失敗数に加え、成功と失敗を繰り返すテストを考慮した健康度を計算します。失敗した実行からNova Actの操作記録やセッション記録へ進み、原因を調べられます。権限は管理者、チーム責任者、編集者、実行者、閲覧者という役割で分けます。別チームへ共有する場合は、本人の役割と共有で許した範囲のうち狭い方が適用されます。広い共有を受けても、閲覧者が編集できるわけではありません。品質の担当者と基盤の管理者には、表示上の便利さに加えて、後段で権限を強制できるかが確認点になります。指標は実行済みのテストの状態を示し、未作成のテストが必要な範囲を覆っているかまでは自動的に説明しません。 所有者が結果から対応へ進めるかを確かめる 導入するチームでは、失敗の通知を受けるだけでなく、担当者が記録から修正へ進めるかが論点になります。画面を操作するAIの失敗と、製品の不具合を見分ける必要があると見られます。健康度の一つの数値だけで公開の可否を決めず、重要な操作の検証結果や最近の変更を合わせて見る方法が考えられます。環境ごとに結果を分ければ、検証用の設定による失敗を本番の問題と混同しにくくなります。チーム間の共有を変えた際は、閲覧や実行が必要な相手へ届き、編集は意図した範囲に限られるかを確認する余地があります。参考実装の運営には、保存する実行記録と指標の費用、利用者の追加と削除の手間も伴います。テストの数を増やす前にアプリの所有者を定め、失敗を放置しない経路を作ることが、継続した品質管理につながると考えられます。利用者の異動に合わせた権限の見直しも、日常の管理に含まれます。