DevOps AgentのRelease testing機能を試してみた
リテールアプリ共創部@大阪の岩田です。
6/17付のアップデートにてDevOps Agentにリリース管理の機能が追加されました。
この機能のうち、コードレビューの機能については先日のブログでご紹介しました。
今回はもう1つの目玉である自律リリーステストについて検証してみます。
機能概要
この機能はリリーステストエージェントが実際のシステムの動作環境を用いてテストを実行する機能です。ドキュメントでは以下のテストに対応していると記載されています。
- 探索的UAT（ユーザー受け入れテスト）
- 回帰テスト
- ユーザージャーニー検証
- 統合テスト
- エッジケース探索
テスト実行中には読み取り操作だけでなく書き込み操作も実行されるため、基本的にステージング環境を対象に実行することが推奨されています。
テストがトリガーされると、リリースエージェントは以下の処理を実行します。
- テスト計画の生成
- テストの実行
- 結果のレポート
テストの種別としてはUIテストとAPIテストの2つに対応しています。本ブログでは後ほど実際にAPIテストの実行を試していきます。
テストプロファイル
テストを実行するには「テストプロファイル」の定義が必要です。「テストプロファイル」とはテスト対象アプリケーションに関する定義で、対象アプリケーションの種別やエンドポイント、テスト用の認証情報の定義などを定義します。認証情報を利用する場合は Secrets Managerに保存した認証情報を取得・利用してくれます。
APIテストの場合はOpenAPI/SwaggerのYAML/JSONファイルの指定が必須となっており、アップロードしたAPI仕様書をもとにAIが必要なテストケースを考えてくれます。便利。
テストの実行方法
テストの実行方法として公式ドキュメントでは以下が紹介されています。
- テストプロファイルの一覧から実行する方法
- DevOps Agentのウェブアプリからテストプロファイルの一覧を表示して実行する一番シンプルな方法です。
- DevOps Agentのチャットから実行する方法
Run test profile my-test-profileのようにチャットから指示して実行する方法です。
- エディタ/IDEからテスト実行する方法
- Kiro PowerやClaude Codeプラグインを使うと自分好みのエディタやIDEからテスト実行をトリガーし、テスト結果をもとにコーディングエージェントに不具合を修正させるといったことが可能です。
- GitHub Actionsから実行する方法
- GitHub Actionsのワークフローにaws-actions/devops-agent-qaを組み込む方法です。
やってみる
それではさっそくやってみましょう。このブログではREST APIのサンプルとして有名なPetstore APIを対象にテストを実行していきます。
まずDocker HubでPetstore API用のイメージが公開されているので、このイメージをECSサービスにデプロイし、インターネット経由でhttpsアクセス可能にしました。
PetStore APIの準備ができたらDevOps Agentを設定していきます。
テストを実行
自律リリーステストを実行するための準備として、まず「テストプロファイル」が必要になります。ウェブアプリのメニューから「変更」を選択し、「テストプロファイルを表示」をクリックします。
すると作成済みのテストプロファイル一覧が表示されるので、「テストプロファイルを追加する」をクリックします。
テストプロファイルの追加画面です。
今回は以下の内容を入力しました。
- 名前: pet-store-api
- ターゲットURL: PetStore APIコンテナの前段で稼働しているALBのエンドポイント
- テストタイプ: APIテスト
- API仕様: 「手動で貼り付ける」を選択し、PetStore APIのAPI仕様(swagger.json)の中身を貼り付け
登録できたらテストプロファイル一覧の画面から「テストを開始」をクリックします。
オプションでテストインテントが指定できるので、今回は「statusがavailableのペット一覧が正常に取得できることをテストする」と指定してみました。
確認をクリックするとテストが実行開始されるのでしばらく待ちましょう。
ECSタスクのログからもテストが実行されていることが分かります。
実行結果
テスト実行開始から1時間半ほど待つとテストが完了していました。結構時間がかかりますね。
詳細画面を開くと以下のようになっていました。「タイムライン」、「レポート」、「テストケース」と3つのタブがあり、それぞれのタブから詳細が確認できます。まずは「タイムライン」のタブです。
API仕様書とテストインテントをもとに、以下の手順でテストを実行していくようです。
- API仕様の解析
- API関係のマッピング
- 依存関係のマッピング
- テストする機能の特定
- テストインテントに対応するオペレーションの特定
- テストジャーニーの検出
- テストの実行
「テストジャーニーの検出」を展開すると、どのようなテストジャーニーが必要と考えたのか？DevOps Agentの思考プロセスが垣間見えますね。
続いて「レポート」タブです。
テスト結果の概要がグラフィカルに分かりやすく表示されています。今回のテスト結果では「強度」と「弱点」のそれぞれに以下のように記載されていました。
強度はこちら。
- Excellent functional coverage with 100% pass rates across CRUD lifecycle (24/24), cross-resource flows (43/43), and data integrity (6/6) scenarios.
- High overall pass rate of 98.7% among executed journeys, indicating core API behavior is reliable.
- Only a single confirmed functional defect, which is well-characterized with a clear root cause.
- Strong handling of complex multi-step and cross-resource workflows, suggesting solid state management and data consistency.
弱点はこちら。
- A large share (~26%) of journeys were blocked, predominantly by server errors, leaving significant coverage unverified and inflating confidence in the pass rate.
- Negative-scenario testing is the weakest category at 75% and is the source of the only confirmed defect.
- Input validation is not consistently enforced against the documented contract, as shown by the missing enum validation.
- The high blocked count limits the reliability of the overall quality conclusion until those journeys are re-executed.
これらの内容からPetStore APIの良い点、改善点それぞれの概要が把握できます。
最後に「テストケース」タブです。こちらには各ジャーニーがどういう順番でどのAPIを呼び出していったのか詳細な履歴が確認できます。
テストケースのフィルタも可能になっており、「失敗」したテストケースにフィルタすると以下のような表示になりました。
「リクエスト/レスポンスを表示する」のリンクをクリックすると、タイトルの通りリクエストとレスポンスの詳細が確認できます。今回のテストではクエリストリングのstatusにEnum値で定義されていない値を指定したにも関わらず、400エラーではなく200エラーが返却されたためテストが失敗しています。
確かにAPI仕様書では400エラーのDescriptionに Invalid status valueと記載されているので、期待値と異なる挙動になっていそうです。
テストジャーニーの「詳細を表示」リンクを展開すると、以下の通り詳細な説明が記載されていました。
The journey J-102 verifies that GET /pet/findByStatus returns 400 for an invalid enum status value.
Step 2 sent status='unknown_status' and expected 400 (which the API spec explicitly documents as the 'Invalid status value' response).
However, the server returned 200 with an empty array [].
I confirmed this is a real server-side contract violation via two direct probes: both 'unknown_status' and 'totally_invalid_value_xyz' returned 200 with [] instead of the documented 400.
The valid value 'available' correctly returns 200 with results.
This means the server fails to validate the 'status' query parameter against its documented enum (available, pending, sold) and silently accepts invalid input — a missing input validation defect that contradicts the documented API contract.
This is NOT an agent-fixable issue.
Weakening the test expectation from 400 to 200 is explicitly prohibited and would hide the real validation defect.
The test intent (verifying enum validation) is correct.
I recorded the bug via report_server_bug (classified high severity).
Classifying as FAILED due to a confirmed server bug: the server accepts invalid input without the documented error response.
確かにごもっともな指摘ですね！
まとめ
DevOps Agentの自律リリーステストについて簡単に検証してみました。
自分でE2Eテストのシナリオを書かなくてもAIにお任せするだけで色々なテストジャーニーを自動生成&実行してくれるのは非常に便利だと感じました。また、今回失敗したテストケースのように、API仕様書の記述ミスを検出するのにも非常に役立ちそうです。
うまく開発プロセスの中に組み込んでいきたいですね！
