はじめに
第3回(仕様とモデルの突き合わせ編)では、エージェントに O11 のモデルと業務ルールを突き合わせさせ、仕様と実装の食い違いを2つ(R4 と A5)見つけました。
第4回の今回は、その結果をもとに mabl でテストを作り、実行します。ポイントは、テストの期待値を「アプリの今の動き」ではなく「仕様」から作ることです。
| 回 | 内容 |
|---|---|
| 1. 概要編 | なぜ独立した検証が必要か、考え方の核、全体の構成 |
| 2. 環境構築編 | Service Studio の MCP と mabl MCP を Claude Code につなぐ |
| 3. 仕様とモデルの突き合わせ編 | AIに仕様と実装の食い違いを見つけさせる |
| 4. テスト作成・実行編(この記事) | 仕様どおりの期待値で mabl のテストを作る |
| 5. 修正ループ編 | AIが直し、人が Compare and Merge で取り込む |
| 6. メンテナンス編 | 同期コマンドとバージョン管理で回し続ける |
最初に作る3つのテスト
最初は、次の3つに絞りました。仕様どおりに動くところは合格し、食い違いのあるところだけが失敗する、という対比がいちばん分かりやすいからです。
| # | テスト名 | ユーザー | 業務ルール | 今の実装での見込み |
|---|---|---|---|---|
| 002 | 申請の作成: 下書き保存から申請 | 申請者 | S1 など | 合格 |
| 003 | 申請の作成: 金額50,000円ちょうどは説明が必須 | 申請者 | R4 | 失敗(不具合を検出) |
| 004 | 承認待ち一覧: 自分の申請は承認できない | 承認者 | A5 | 失敗(不具合を検出) |
003 は境界値のテストなので、49,999円・説明なしでは申請できること、50,000円・説明なしではエラーになることの両側を1本のテストで確かめます。
2段階で進める
いきなり mabl でテストを作らせず、まず「何を確かめるか」をファイルにしてから作る、という2段階で進めました。
1段階目:プロンプトファイルを作る
Claude Code に、突き合わせの結果をもとに、テストごとのプロンプトファイルを作らせます。この段階では、まだ mabl ではテストを作りません。
results/analysis/ の最新の分析結果にあるテスト計画(T-R4、T-A5)と、
申請の正常系(下書き保存から申請まで)のテスト1件について、
prompts/_templates/create-test.md に沿ってプロンプトファイルを
apps/ExpenseApp/tests/prompts/create/ に作成し、catalog.md に行を追加してください。
- 連番は 002(正常系)、003(T-R4)、004(T-A5)とします。
- 期待結果は business-rules.md の文言どおりに書いてください。
- テストで使う申請のタイトルには、実行ごとに異なる値(日時など)を含めてください。
- 利用日は「今日」ではなく「昨日」を使ってください。
まだ mabl ではテストを作成しないでください。commit もしないでください。
指示の中の細かい決まりには、それぞれ理由があります。
| 決まり | 理由 |
|---|---|
| 期待結果は business-rules.md の文言どおり | 期待値を仕様から作るため |
| タイトルに実行ごとに異なる値を含める | 前回の実行で作ったデータと区別し、一覧で確実に見つけるため |
| 利用日は「昨日」 | 個人環境のサーバーは UTC で動くので、日本時間の朝に「今日」を使うと未来の日付と判定されることがあるため |
できあがったファイルを人が読み、観点に漏れがないかを確認します。たとえば 003 で境界の両側(49,999円と50,000円)を確かめる手順になっているか、といった点です。
2段階目:mabl でテストを作る
プロンプトファイルに問題がなければ、1件ずつ mabl でテストを作らせます。
apps/ExpenseApp/tests/prompts/create/002 のプロンプトで、mabl にテストを作成してください。
作成が終わったら、テスト ID をプロンプトファイルと catalog.md に記録してください。
Claude Code は mabl MCP を通じて mabl のテスト作成のエージェントに依頼し、mabl のエージェントが実際にブラウザでアプリを操作しながらテストを組み立てます。作成の後、Claude Code はテストを実行して結果を確かめ、テストの側に問題があれば直して再実行します。
mabl のエージェントにもルールを渡す
ここで1つ、気をつけたいことがあります。第2回で書いた CLAUDE.md は、Claude Code が読むルールです。実際にブラウザを操作してテストを作るのは mabl のエージェントで、こちらは CLAUDE.md を読みません。
mabl には、ワークスペースの AI エージェント(テストの計画、テストとフローの作成、結果の分析など)に、毎回組み込まれる指示を登録する機能(Agent instructions)があります。今回は、次の4つを登録しました。いずれも、適用範囲を ExpenseApp のアプリケーションに絞っています。
| 指示 | 対象のエージェント | 内容 |
|---|---|---|
| 期待結果は指示どおりに作る | 作成、結果分析 | アプリの実際の動作に合わせて、期待結果を変えない |
| ログインとテストデータ | 作成 | ログインは共有フローを使い、データはテストの中で作る |
| OutSystems Reactive アプリの操作 | 作成 | 非同期の表示を待つ。メッセージは操作の直後に確認する。ウィジェット名で要素を特定する |
| 業務ルール | 作成、結果分析 | business-rules.md の業務ルール(仕様だけ) |
いちばん大事なのは、1つ目の「期待結果は指示どおりに作る」です。
テストの期待結果(アサーション)は、ユーザーが指示した期待結果のとおりに作成してください。
アプリの実際の動作が指示した期待結果と異なる場合でも、アサーションを実際の動作に合わせて変更しないでください。
その場合は、指示どおりのアサーションのまま、食い違いがあったことをテストの説明に記載してください。
結果分析では、アプリの動作が期待結果と異なることで失敗している場合、テストの不具合ではなくアプリケーションの不具合の可能性として扱ってください。
テストを作るエージェントは、アプリを操作しながらテストを組み立てます。そのため、指示した期待結果と違う動きに出会うと、気を利かせて「観察した動き」に合わせたアサーションを作ってしまうことがあります。そうなると、仕込んだ不具合が「正しい動き」としてテストに固定され、第1回で書いた落とし穴にそのまま落ちます。それを防ぐための指示です。
なお、仕込んだ不具合の内容は、どの指示にも書いていません。エージェントが答えを知っていたら、検証にならないからです。
不具合を伝えなくても、期待値は仕様どおりに残った
この指示が本当に効くのかを確かめるために、003 と 004 で依頼の仕方を変えてみました。
003 では、リハーサルとして「今の実装では、50,000円の確認で失敗する見込み」と、作成のエージェントに伝えました。
004 では、今の実装の動きには一切触れず、次のように伝えました。
- 期待結果は business-rules.md の A5 に従ってください。作成エージェントへの指示では、今の実装の動作には触れず、
「期待結果を実際の動作に合わせないこと」「期待結果と違う場合は失敗してよいこと」だけを伝えてください。
- 作成後の通しの実行で A5 の確認が失敗した場合は、テストを直さずに、どのステップでどのような結果になったかを報告してください。
作成のエージェントは、テストを作る途中で実際に「承認」ボタンを押し、自分の申請が承認できてしまう動きを見ています。それでも、作られたアサーションは仕様どおりでした。
| エージェントが見た動き | 作られたアサーション | |
|---|---|---|
| 004 | 自分の申請を承認できてしまった | エラー「自分の申請は承認できません」が表示される / 申請が承認待ち一覧に残る |
答えを教えなくても、Agent instructions と仕様だけで、期待値が仕様どおりに保たれることを確かめられました。
実行する
作った3本のテストは、mabl のプランにまとめて実行します。今回は2つのプランを用意しました。
| プラン | 実行 | 中身 |
|---|---|---|
| Smoke | 24時間ごと(自動)、デモ前(手動) | ステージ1で3人のユーザーのログイン、ステージ2で 002 |
| Regression | 手動(デモ前、修正後) | 002、004、003 |
プランの中では、テストごとに使うユーザー(クレデンシャル)を切り替えられます。
結果:3件中2件が、不具合で失敗
Regression プランを実行した結果です(約9分)。
| テスト | 結果 | 失敗したステップ | 業務ルール |
|---|---|---|---|
| 002 下書き保存から申請 | 成功 | — | — |
| 003 金額50,000円ちょうどは説明が必須 | 失敗 | 8.8 エラーメッセージが表示されない | R4 |
| 004 自分の申請は承認できない | 失敗 | 5.5 エラーにならずに承認された | A5 |
003 は、49,999円・説明なしの申請や一覧での確認はすべて合格し、50,000円・説明なしのエラーメッセージを確かめるステップだけが失敗しました。境界のどちら側が仕様と違うのかまで、テストの結果から分かります。
正常系(002)は合格し、仕様と食い違う場所だけが失敗する。期待値を仕様から作ったテストが、狙いどおりに不具合を検出した形です。
失敗の原因を、何を基準に判断するか
mabl は、失敗したテストの原因を自動で分析します。今回の結果では、2つの失敗で分析の判断が分かれました。
| テスト | mabl の分析での分類 |
|---|---|
| 003(R4) | リグレッション(アプリの不具合) |
| 004(A5) | テスト実施の問題。「仕様が変わった可能性があるので、テストの期待結果を直すように」という提案 |
003 については、mabl の分析も「テスト自体に問題はなく、アプリのバリデーションを確認・修正すること」と判断しています。
一方 004 は、テスト側の問題と分類されました。「自分の申請は承認できない」は画面を見ただけでは分からない業務ルールなので、仕様を知らなければ「仕様が変わったのでは」としか判断できません。
この結果を Claude Code に要約させたところ、Claude Code は business-rules.md の A5 を根拠に、この分類を採用せず、アプリの不具合として扱いました。CLAUDE.md に書いた「期待値の正本は business-rules.md」というルールが、実際に働いた場面です。
そのうえで、mabl の結果分析のエージェントも同じ基準で判断できるように、Agent instructions に4つ目の「業務ルール」を追加しました。登録したのは business-rules.md の仕様だけで、「今の実装には不具合がある」といった情報は書いていません。
失敗の原因を判断する拠り所も、テストの期待値と同じく仕様です。
テストを安定させる工夫
テストを作って回す中で、実際につまずいて直したことをまとめておきます。
| つまずいたこと | 対処 |
|---|---|
| 一覧が1ページ10件で、作った申請が2ページ目に回り、別の行を確認していた | 行を確認する前に、「タイトルで検索」欄で絞り込む |
| タイトルが前回の実行と重なり、どの行か分からない | タイトルに実行日時を付ける(例:正常系テスト 20261022-163720) |
| 日本時間の朝に「今日」の利用日が未来の日付と判定された | 利用日は「昨日」にする(サーバーは UTC) |
| AI による判定のアサーション(GenAI アサーション)が、毎日の実行で結果がぶれる可能性がある | 決まった値と比べる通常のアサーションに置き換える |
ドロップダウンの選択状態(option:checked)が「表示されていない」と判定された |
選択中の項目名を JavaScript で読み取って比べる |
| 承認待ち一覧には検索欄がなく、申請中のデータが溜まると目的の行が2ページ目に回る | デモ前に、申請中のまま残ったデータを片付ける |
どれも OutSystems に限らず起きることですが、テストを AI に作らせるときは、こうした決まりを Agent instructions やプロンプトのテンプレートに書いておくと、次に作るテストでも同じ失敗をせずに済みます。
まとめ
| やったこと | ポイント |
|---|---|
| 2段階で作る | まずプロンプトファイルで「何を確かめるか」を決め、人が確認してから mabl で作る |
| mabl のエージェントにもルールを渡す | CLAUDE.md は mabl のエージェントには届かない。Agent instructions に書く |
| 期待結果は指示どおりに作る | 不具合を伝えなくても、アサーションは仕様どおりに残った |
| 実行結果 | 3件中2件が仕様との食い違いで失敗。境界のどちら側が問題かまで分かる |
| 失敗の判断 | 判断の拠り所も仕様。mabl の分析にも業務ルールを渡す |
次回は、見つかった不具合を AI に直させ、人が Compare and Merge で確認して取り込み、テストで再検証する修正ループを紹介します。
この記事は個人の検証結果をまとめたものです。所属する組織の公式な見解ではありません。mabl に関する記述は、公開されている製品情報とドキュメントにもとづいています。