Amazon Nova Act を用いたエージェント型 QA 自動化によるソフトウェアデリバリーの加速 – 第 2 部

本番環境向けの品質保証（QA）ワークフローでは、単一のテスト実行だけでは不十分です。テストを回帰スイートに整理してバッチ処理で実行し、継続的インテグレーション・継続的デリバリー（CI/CD）パイプラインに統合することで、テスト結果がデプロイのゲートとして自動的に機能するようにする必要があります。

前回の投稿では、Amazon Nova Act を活用したエージェント型 QA 自動化のためのリファレンスソリューション「QA Studio」を紹介しました。ここでは、自然言語で個々のユースケースを定義し、AI が駆動する視覚ナビゲーションによってオンデマンドで実行し、完全な実行履歴の可視化を通じて実行結果を検証する方法を示しています。

今回の投稿では、この基盤を拡張し、QA Studio がどのようにテストスイートを通じてバッチ回帰テストとパイプライン統合に対応しているかを解説します。テストスイートは個々のユースケースを整理・並列実行する役割を果たし、コマンドラインインターフェース（CLI）によってエージェント型テストを自動化された CI/CD パイプラインに組み込むことが可能になります。

組織的な回帰テストのためのテストスイート

QA Studio を使えば、特定のユーザーフローを検証する個々のユースケースを「テストスイート」というコレクションにグループ化し、まとめて実行できます。これにより、機能領域全体にわたる構造化された回帰テストが実現します。

スイートはバッチ処理として実行され、並列処理が行われます。スイートが実行されると、各ユースケースは AWS Fargate 上の Amazon Elastic Container Service (Amazon ECS) ワーカータスク上で独立して動作します。各ユースケースが個別の Fargate ワーカータスクで実行されるため、20 個のテストを含むスイートも順次ではなく並列に実行可能です。これにより、逐次実行と比較してスイートの総実行時間を短縮できます。

スイートは機能領域、リリース段階、またはテスト目的に応じて整理できます。例えば、すべてのデプロイで重要なパスを検証するスモークテストや、アプリケーション全体を対象とする回帰テスト、リリース前にクロス機能ワークフローを検証する統合テストなどが該当します。

テストスイートの作成と管理

QA Studio の Web インターフェースでは、名前、説明、オプションのタグを指定してテストスイートを作成し、既存のユースケースを追加できます。各ユースケースは、開始 URL、変数、シークレット、ヘッダーなどの設定をそのまま保持します。スイート実行時には、これらの設定が各ユースケースに対して個別に適用されます。

スイート実行と結果

スイート実行時、QA Studio は各ユースケースごとに個別の実行レコードを作成し、ワーカーキューに配信します。スイート実行ページでは、成功した・失敗した・現在進行中のユースケース数を集計して表示できます。特定のテストが失敗した場合でも、その結果を詳細に確認でき、軌跡ログやスクリーンショット、セッション記録などを閲覧可能です。

各スイートは独自の履歴を保持しており、回帰テストの安定性を長期的に追跡できます。一貫したパスは機能への信頼を高め、断続的な失敗は改善が必要な領域を示します。

QA Studio CLI を用いた CI/CD 統合

QA Studio の Web インターフェースは、対話型のテスト作成やオンデマンド実行には適しています。一方、CI/CD パイプラインでは異なるインターフェースが必要です。具体的には、構造化された出力を持つコマンドライン実行、非対話的な認証、そしてパイプラインオーケストレーターと連携できる終了コードが求められます。

QA Studio CLI（qa-studio）はこのインターフェースを提供します。これは Web アプリケーションと同じ API バックエンドに接続しますが、テストを Fargate ワーカーに配信するのではなく、CLI を実行しているマシン上（CI/CD ランナーなど）で Amazon Nova Act を使用して実行します。結果は QA Studio のデプロイメントへ報告されます。

インストールと認証

QA Studio CLI はプロジェクトの GitHub リポジトリに含まれています。リポジトリをクローンした後、オプションのランナー依存関係を含む Python パッケージとして CLI をインストールしてください。

pip install -e "./qa-studio-cli[runner]"

CI/CD環境では、CLIはOAuth 2.0のクライアント認証をサポートしています。必要なスコープ（api/suite.read、api/suite.write、api/executions.read）を設定して、QA StudioのWebインターフェースでOAuthクライアントを作成します。

api/executions.write、api/usecases.read、api/usecases.execute などの権限を付与した後、これらの認証情報をパイプライン環境変数として設定します。

export OAUTH_CLIENT_ID="your-client-id"
export OAUTH_CLIENT_SECRET="your-client-secret"
export OAUTH_TOKEN_ENDPOINT="https://your-cognito-domain.auth.region.amazoncognito.com/oauth2/token"

CLI はアクセストークンの要求とキャッシュを自動的に行い、期限切れになった場合は自動的に更新します。対話型のブラウザログインは不要です。

テストとスイートの実行

qa-studio run コマンドを使用すると、個々のユースケースやテストスイート全体を実行できます:

# Run a single test
qa-studio run --usecase-id test-123

# Run a test suite
qa-studio run --suite-id suite-456

環境と変数の上書き

CI/CD パイプラインでは、異なる環境に対して同じテストを繰り返し実行する必要があるケースが頻繁に発生します。CLI では、QA Studio に保存されたテスト定義を変更することなく、テストの動作を調整するための複数のオーバーライドメカニズムをサポートしています。

--base-url フラグは、開始 URL のドメインを置き換える一方で、パスやクエリパラメータはそのまま保持します。これにより、単一のテストで開発環境、ステージング環境、本番環境のいずれも対象とすることが可能になります。

# Run against staging
qa-studio run --suite-id suite-456 --base-url https://staging.example.com

# Run against production
qa-studio run --suite-id suite-456 --base-url https://production.example.com

--var フラグは、ユースケースで定義されたテンプレート変数を上書きします。テスト手順内で {{VariableName}} 構文を参照している変数は、実行時に置換されます。これにより、テスト定義を複製することなく、環境固有の設定に対応できます。

# Override credentials for a specific environment
qa-studio run --usecase-id test-123 \
    --var username=staging_user \
    --var password=staging_pass \
    --var api_key=staging_key_123

--region フラグでブラウザを実行する AWS リージョンを指定し、--model-id で Amazon Nova Act モデルのバージョンを選択します。

qa-studio run --usecase-id test-123 \
    --region eu-central-1 \
    --model-id nova-act-v1.0

ヘッダーとシークレット

テスト実行時に送信されるリクエストに、カスタム HTTP ヘッダーを定義できます。これは、認証トークンや機能フラグ、アプリケーションが要求する独自識別子などを扱う際に役立ちます。ヘッダーはユースケースの設定で構成され、Web インターフェースおよび CLI での実行の両方で自動的に適用されます。

シークレットは、パスワードや API キー、トークンといった機密情報を安全に保存するための仕組みです。AWS Secrets Manager に格納され、保存時にも暗号化されます。QA Studio では、実行ログや履歴記録にシークレットの値が書き込まれないように設計されています。テスト手順ではシークレット名を参照し、実際の値は実行時に取得します。この分離により、CI/CD パイプラインで認証情報を必要とするテストを実行しても、パイプラインの設定やログに認証情報が露出することはありません。

終了コードとパイプライン統合

このCLIでは、パイプラインの成功と失敗の状態を直接示す終了コードを使用します。

この 3 ステートモデルにより、パイプラインはテストの失敗（終了コード 1）とインフラの問題（終了コード 2）を明確に区別できます。それぞれのケースに対して、異なる通知やリトライ戦略を設定することが可能です。

--format フラグは出力形式を制御します。デフォルトの json 形式はプログラムによる利用に適した構造化された出力を提供します。一方、human 形式はパイプラインのログで確認できる読みやすいサマリーを提供します:

qa-studio run --suite-id suite-456 --format human

実行中は、CLI が QA Studio に実行レコードを作成し、ステップの状態をリアルタイムで更新します。また、トラジェクトリログやセッション記録を含むアーティファクトもアップロードされます。Web インターフェースでは、CLI 経由でトリガーされた実行を手動で開始した実行と併せて監視でき、テストの起動方法に関わらず統一的な実行履歴を維持できます。

CI/CD プラットフォームの例

以下の例は、QA Studio を一般的な CI/CD ツールに統合する方法を示しています。各例では、OAuth クライアント認証情報と AWS 認証情報をパイプラインのシークレットとして保存していることを前提としています。

GitHub Actions

name: QA Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  smoke-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Install QA Studio CLI
        run: pip install -e "./qa-studio-cli[runner]"

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Run Smoke Tests
        env:
          OAUTH_CLIENT_ID: ${{ secrets.OAUTH_CLIENT_ID }}
          OAUTH_CLIENT_SECRET: ${{ secrets.OAUTH_CLIENT_SECRET }}
          OAUTH_TOKEN_ENDPOINT: ${{ secrets.OAUTH_TOKEN_ENDPOINT }}
        run: |
          qa-studio run \
            --suite-id ${{ vars.SMOKE_TEST_SUITE_ID }} \
            --base-url https://staging.example.com \
            --format human

      - name: Upload Artifacts
        if: always()
        uses: actions/upload-artifact@v3
        with:
          name: test-artifacts
          path: ~/.qa-studio/artifacts/

アーティファクトアップロードステップにある if: always() 条件は、テストが失敗した場合でもテスト記録やログを保持することを保証します。これにより、障害の原因を調査するために必要なデバッグコンテキストが提供されます。

GitLab CI

stages:
  - test

smoke-tests:
  stage: test
  image: python:3.11
  before_script:
    - pip install -e "./qa-studio-cli[runner]"
  script:
    - |
      qa-studio run \
        --suite-id $SMOKE_TEST_SUITE_ID \
        --base-url https://staging.example.com \
        --format human
  variables:
    AWS_DEFAULT_REGION: us-east-1
  artifacts:
    when: always
    paths:
      - ~/.qa-studio/artifacts/
    expire_in: 7 days
  only:
    - main
    - merge_requests

regression-tests:
  stage: test
  image: python:3.11
  before_script:
    - pip install -e "./qa-studio-cli[runner]"
  script:
    - |
      qa-studio run \
        --suite-id $REGRESSION_SUITE_ID \
        --timeout 7200 \
        --format human
  variables:
    AWS_DEFAULT_REGION: us-east-1
  artifacts:
    when: always
    paths:
      - ~/.qa-studio/artifacts/
    expire_in: 7 days
  only:
    - schedules

GitLab CI 変数（OAUTH_CLIENT_ID、OAUTH_CLIENT_SECRET、OAUTH_TOKEN_ENDPOINT、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY）は、以下のように設定する必要があります。

プロジェクト設定で保護され、マスクされた CI/CD 変数です。

regression-testsジョブは、GitLabのスケジュールトリガーを使用しており、コードプッシュ時ではなくパイプラインスケジュールによってトリガーされた場合にのみ実行されます。

Jenkins

pipeline {
    agent any

    environment {
        AWS_DEFAULT_REGION = 'us-east-1'
    }

    stages {
        stage('Setup') {
            steps {
                sh '''
                python3.11 -m venv venv
                . venv/bin/activate
                pip install -e "./qa-studio-cli[runner]"
                '''
            }
        }

        stage('Smoke Tests') {
            steps {
                withCredentials([
                    string(credentialsId: 'oauth-client-id', variable: 'OAUTH_CLIENT_ID'),
                    string(credentialsId: 'oauth-client-secret', variable: 'OAUTH_CLIENT_SECRET'),
                    string(credentialsId: 'oauth-token-endpoint', variable: 'OAUTH_TOKEN_ENDPOINT'),
                    string(credentialsId: 'aws-access-key-id', variable: 'AWS_ACCESS_KEY_ID'),
                    string(credentialsId: 'aws-secret-access-key', variable: 'AWS_SECRET_ACCESS_KEY')
                ]) {
                    sh '''
                    . venv/bin/activate
                    qa-studio run \
                        --suite-id ${SMOKE_TEST_SUITE_ID} \
                        --base-url https://staging.example.com \
                        --format human
                    '''
                }
            }
        }
    }

    post {
        always {
            archiveArtifacts artifacts: '~/.qa-studio/artifacts/**/*',
                allowEmptyArchive: true
        }
    }
}

Jenkins は、ビルド環境にシークレットを注入する際に withCredentials ブロックを使用し、コンソール出力からそれらを隠蔽します。また、post.always ブロックはビルドの結果に関わらずテスト成果物をアーカイブします。

結論

テストスイートと CI/CD 連携により、QA Studio は単なる対話型のテスト作成ツールから、継続的な品質保証のためのプラットフォームへと進化します。テストスイートでは回帰テストのカバレッジを並列実行可能な管理しやすいコレクションとして整理できます。また CLI を活用すれば、環境のオーバーライドや安全な認証情報の処理、パイプラインの成否に対応する終了コードの取得を通じて、エージェントによるテスト実行を自動化されたパイプラインに組み込むことが可能になります。

これらの機能は、前回の投稿で説明した基盤の上に成り立っています。具体的には、自然言語によるテスト定義、AI 駆動の視覚的ナビゲーション、そしてエンドツーエンドの軌跡可視化です。これらを組み合わせることで、Amazon Nova Act を用いたエージェント型 QA オートメーションが既存のソフトウェアデリバリーワークフローにどのように統合されるかが示されます。これにより、フレームワーク固有のテストコードを維持する必要なく、自動化された品質フィードバックを提供することが可能になります。

今後の記事では、エージェント型テスト自動化がモバイルアプリケーションにどのように拡張されるかについて探求する予定です。

QA Studio リファレンスソリューション（テストスイートおよび CLI 統合を含む）は GitHub で公開されています。デプロイ手順や詳細なドキュメントについては、プロジェクトの README をご覧ください。

執筆者について

Vinicius Pedroni

Vinicius は AWS のシニアソリューションアーキテクトで、トラベル・ホスピタリティ業界を担当しています。エッジサービスと生成 AI に注力しており、顧客がクラウド移行の適切なタイミングで最適な戦略を採用できるよう支援することに情熱を注いでいます。

Jan Wiemers

Jan は AWS のシニアソリューションアーキテクトで、トラベル・交通・物流業界の顧客を担当しています。ソフトウェア業界での 20 年以上の実績を持つ彼は、AI プロダクト開発ライフサイクルとテスト自動化に注力し、顧客が AI ドライブ型のソリューションを構築、テスト、デプロイするスピードを加速させるお手伝いをしています。

Ryan Canty

ライアン氏は、Amazon AGI Labs のソリューションアーキテクトです。大規模なエンタープライズソフトウェアシステムの設計とスケーリングに深い専門知識を持ちます。彼は顧客と共に、AWS サービスである Amazon Nova Act を活用して、信頼性の高い AI エージェントの群れを構築・展開しています。このサービスは、大規模な UI ワークフローの自動化を実現します。