品質保証（QA）自動化の導入が組織内で進むにつれて、テストの作成とは無関係な新たな問題が現れます。プラットフォームチームがテスト自動化を立ち上げ、次に2番目のチームが参加を希望し、さらに十数のチームが続きます。すぐに数百のテストケースが異なる製品や squad に属し、誰もが他のチームのテストを見ることができるようになります。誰も一目で基本的な質問に答えられません。このアプリケーションのテストカバレッジは今健全なのか？テストの作成はボトルネックではなくなり、テストを整理し、誰がそれらに触れられるかを制御することが仕事になります。さらに、誰がこのアプリケーションとそのテストを所有し、カバレッジが低下したときに誰が責任を負うのかという関連する質問が続きます。明確な所有者がいなければ、健全性の問題は誰にも帰属しません。
最初の投稿では、Amazon Nova Actで構築されたリファレンスソリューションであるQA Studioを紹介しました。チームは自然言語でテストを定義し、AI駆動の視覚ナビゲーションを通じて実行できます。2番目の投稿では、テストスイートとCI/CDパイプラインでのバッチ回帰テスト用のCLIを追加しました。この投稿では、QA Studioを組織全体に拡張するのに役立つ2つの機能を説明します。1つ目はアプリケーションで、テストを整理し健全性メトリクスを報告します。2つ目はチームベースのユーザー管理で、誰が何を見て変更できるかを制御します。
QA Studioのアプリケーションは、テスト対象のシステム（ウェブサイト、ウェブアプリ、サービスフロントエンド）を表します。これはテストのコレクションに家と所有者を与えるコンテナです。ユースケース（パート1の個々のテスト）とテストスイート（パート2の回帰コレクション）はアプリケーションに属し、その所有権を継承します。展開内のすべてのテストのフラットなリストではなく、各チームは所有するアプリケーション内で作業します。
アプリケーションの作成には、名前、ベースURL、およびオプションの環境セット（開発、ステージング、本番など）が必要です。アプリケーションページから、チームはコンテキスト内で直接新しいユースケースを作成し、既存のものを追加し、テストスイートにグループ化できます。ここでQA Studioは実行するテストの健全性を報告します。
テストは結果を生成しますが、その結果を時間の経過とともに理解することが、単一のビルドがリリース準備完了かどうかだけでなく、アプリケーションの開発ライフサイクルが健全かどうかをチームに伝えます。QA Studioは各実行の結果をAmazon CloudWatchカスタムメトリクスとして記録し、アプリケーションと環境でディメンション化します。そして、アプリケーションページの健全性ビューに変換します。ページ上部では、選択したウィンドウの合格率、総実行数、現在の失敗数という3つの数値で即時の質問に答えます。さらに、QA Studioは0〜100の健全性スコアを計算します。スコアは合格率から始まり、フレーキーテストにペナルティを差し引きます。これにより、テストは合格するが合格と失敗の間で揺れ動くアプリケーションが、誤って完璧に見えることはありません。アプリケーションのポートフォリオをスキャンするチームは、各結果を開かなくても安定したものと注意が必要なものを区別できます。
メトリクスタブは現在のスナップショットからトレンドに移ります。チームは7日間ウィンドウ（時間単位の粒度）または30日間ウィンドウ（日単位の粒度）を選択し、QA Studioはその期間の実行、成功、失敗、平均期間をグラフ化します。基盤となるメトリクスには環境ディメンションがあるため、チームはビューを単一環境にフィルタリングできます。たとえば、同じテストセットに対してステージングと本番の動作を比較できます。
2つのビューは、チームの時間を最も消費するテストを対象とします。フレーキーテストビューは、過去7日間に合格と失敗の間で反転した頻度でユースケースをランク付けします。これにより、スイートへの信頼を損なう断続的な失敗が、本番のミスになる前に表面化します。最近の失敗ビューは、迅速なトリアージのために最新の失敗実行をリストします。各失敗はパート1で説明したAmazon Nova Actの軌跡ログとセッション記録にリンクバックします。これにより、「このテストは失敗している」から「エージェントが正確に何を見たか」へワンクリックで移動できます。
メトリクスはチームにアプリケーションの状態を伝えますが、チームベースのユーザー管理はどのアプリケーションがそもそも彼らのものかを決定します。QA Studioはチームを中心にアクセスを整理し、アプリケーションは正確に1つのチームに属します。そのチームのメンバーはそのアプリケーションで作業します。他の誰もそれらを見ることはできません。
各チームメンバーは5つの役割のいずれかを持ち、各役割は下位の役割の権限を含みます。管理者（Admin）はスタジオ全体のすべてのチーム、アプリケーション、ユーザーへのアクセスを持ち、チームの作成やアプリケーションの割り当てを含みます。管理者はチームごとの割り当てではなく、スタジオ全体の役割です。チームリード（Team Lead）は自分のチームメンバーを管理し、チームのアプリケーションを作成します。エディター（Editor）はチームのアプリケーション内でユースケースとテストスイートを作成および編集します。実行者（Executor）はユースケースとスイートを実行しますが、変更はしません。閲覧者（Viewer）はチームのアプリケーションと結果への読み取り専用アクセスを持ちます。役割は累積的であるため、チームリードはエディターのすべての権限を持ち、以下同様に閲覧者まで続きます。ユースケースまたはテストスイートへのアクセスは、それを含むアプリケーションに従います。メンバーがアプリケーションで作業できる場合、役割の範囲内でそのテストで作業できます。これにより、権限管理は数千の個別テストではなく、アプリケーションレベルに保たれます。
管理者はスタジオ全体を見ることができます。ユーザーページには、すべてのアカウントがチームと役割とともに一覧表示され、管理者は誰がどのチームでチームリードを持ち、誰がスタジオ全体の管理者権限を持つかを知ることができます。ここに示すリファレンス展開では、4人のユーザーが2つのチームにまたがっています。2人のチームリード、1人の閲覧者、1人のスタジオ全体の管理者です。チームページは同じデータをチームごとに集約し、各チームのメンバー数とアプリケーション数を並べて表示します。管理者はどのチームが拡大しているかを、いずれかを開かずに確認できます。
チームは完全に孤立して作業することはまれです。プラットフォームチームがアプリケーションを所有し、機能チームがそれを実行する必要があるが、変更能力は渡したくない場合があります。QA Studioは共有アクセスでこれをサポートします。所有チームは別のチームに、表示、実行、または完全のレベルでアプリケーションへのアクセスを付与できます。共有アクセスはシーリングルールに従います。共有アプリケーションに対するユーザーの実効権限は、自身の役割と付与レベルの低い方です。完全アクセスを付与された閲覧者は、役割がシーリングであるため、引き続き閲覧のみです。これにより、所有チームは受信者の役割が許す以上に付与することなく、広く共有できます。
チームリードはスタジオ全体ではなく単一のチーム内で作業します。「マイチーム」を開くと、リードが制御するすべてをカバーする4つのタブが表示されます。メンバー、アプリケーション、ユースケース、共有アクセスです。メンバータブにはチームのメンバーが一覧表示され、リードは任意のメンバーの役割をインラインで変更したり、新しいメンバーを追加したりできるため、日々のアクセス管理は作業に最も近い人に任されます。ここに示すAWSチームでは、リードは2人のメンバー（1人のチームリードと1人の閲覧者）を管理しています。アプリケーションタブにはチームが所有するアプリケーションのみが表示され、それぞれのテストケース数と最終実行時間が示されます。これにより、リードはスタジオ全体のインベントリではなく、自分の範囲に集中できます。共有アクセスタブは、クロスチーム共有が具体化される場所です。ここでAWSチームはAMZNチームにアプリケーションへの表示アクセスを付与しており、リードはそのアクセスの付与、取り消し、またはレベルの変更ができます。付与が表示レベルであったため、AMZNチームのエディターは共有アプリケーションを読み取り専用で表示します。前節のシーリングルールが実際に適用されています。
QA Studioは、以前の投稿で説明したサーバーレス基盤上にチームベースのアクセス制御とメトリクスを構築し、いくつかのAWSサービスを追加します。Amazon Cognitoでは、各チームが役割ごとに1つのCognitoグループのセットにマッピングされます。AWS Lambdaオーソライザーは、リクエストごとに呼び出し元のグループをAPIスコープとチームコンテキストに解決します。Amazon DynamoDBでは、チーム、メンバーシップ、アプリケーションの所有権、クロスチーム共有の付与が既存のシングルテーブル設計に保存されます。Amazon CloudWatchでは、各実行がQAStudio/Executions名前空間でカスタムメトリクスを発行し、アプリケーションと環境でディメンション化されます。メトリクスAPIはそれらを読み戻して健全性ビューとトレンドチャートを構築します。AWS LambdaとAmazon API Gatewayは、バックエンドで2層のアクセスを強制します。呼び出し元の役割が付与するスコープと、呼び出し元のチームがアプリケーションを所有しているか共有されているかを確認するリソースチェックです。アクセスはCognitoグループメンバーシップから派生するため、パート2のOAuthクライアントクレデンシャルフローも同じモデルに適合します。CIパイプラインは、必要なスコープのみを持つマシンIDとして認証します。
アプリケーション、メトリクス、チームベースのアクセス制御はQA Studioリファレンスソリューションの一部であり、AWS CDKを使用して独自のAWSアカウントに展開します。すべてのテストデータ、結果、メトリクスはアカウント境界内に留まります。展開後、管理者はチームを作成し、メンバーと役割を割り当て、アプリケーションをチームに割り当てます。各チームの健全性メトリクスは、テストの実行に伴って入力され始めます。展開手順と構成の詳細については、QA Studio GitHubリポジトリとそのドキュメントを参照してください。
結論として、この投稿ではQA Studioがエージェント型QA自動化を個々のテストから組織全体に拡張する方法を示しました。アプリケーションは各チームのユースケースとテストスイートに家を提供し、合格率、トレンドチャート、フレーキー調整済み健全性スコア、およびCloudWatchメトリクスに基づく失敗トリアージを通じて健全性を報告します。Cognitoに基づくチームユーザー管理は、各チームが所有するアプリケーション内で作業できるようにし、クロスチーム共有は明確なシーリングルールで制限されます。これらの機能は、パート1の自然言語テスト作成とパート2のスイートおよびCI/CD統合に基づいて構築され、QA自動化が可視性や制御を失うことなく多くのチームに拡大するのを支援します。背後にあるエージェントの詳細については、Amazon Nova Act製品ページを参照してください。