AIテストケース自動生成

🔄 前回のおさらい: レッスン1では、41%のコードがAI生成であること、81%のチームがAIテストを導入していること、従来の自動化とAIテストの決定的な違いを学びました。今回は最初の実践スキル——AIでテストケースを生成する方法に入ります。

要件からテストへ、数分で

テストケースの作成はQAで最も時間がかかる作業の一つ。10個の受け入れ基準を持つ典型的な機能は、ハッピーパス、エッジケース、境界値、エラーシナリオをカバーする40〜60のテストケースが必要。手書きだと数日かかる。

AIテスト生成ツールなら数分で完了する。

AIテスト生成の仕組み

AIテスト生成ツールは3段階のプロセスに従う：

1. 入力： 自然言語で要件を提供——ユーザーストーリー、受け入れ基準、API仕様、またはUIのスクリーンショット。

2. 分析： AIが要件を解析し、テスト可能な動作を特定し、パターンからエッジケースを推測し、テストシナリオをマッピング。

3. 出力： 実行可能なテストケースを生成——自然言語（testRigor）、コードスクリプト（Katalon）、またはビジュアルテストフロー（mabl）。

入力（ユーザーストーリー）：

オンラインショッパーとして、チェックアウト時に割引コードを適用して
購入金額を節約したい。

ルール：
- コードは大文字小文字を区別しない
- 各コードは1アカウントにつき1回のみ使用可能
- 期限切れコードはエラーメッセージを表示
- コードの併用不可（1注文に最大1つ）

AI生成テストケース：

1. 有効な割引コードを適用 → 価格が正しく減少することを確認
2. 大文字小文字を変えて同じコードを適用 → 機能することを確認
3. 同じアカウントで同じコードを2回適用 → 「使用済み」エラーを確認
4. 期限切れコードを適用 → エラーメッセージ表示を確認
5. 2つの有効なコードを適用 → 1つしかアクティブにできないことを確認
6. 空のカートにコードを適用 → 適切なエラーを確認
7. コード適用後に最低金額以下まで商品を削除 → コードの挙動を確認
8. コード適用後にページをリフレッシュ → コードが保持されることを確認

4行の要件から、AIが8つのテストシナリオを生成——多くのテスターが最初のパスで見逃すエッジケース（空カート、ページリフレッシュ）を含む。

✅ 確認クイズ: AIテスト生成がエッジケースに優れる理由は？（AIはすべてのルールを体系的に分析し、有効なケースとそのルール違反の両方のテストを生成する。人間はハッピーパスに集中しがちで、スプリント終了前にすべてのエッジケースに到達しないことがある。）

主要ツール

testRigor：自然言語テスト

testRigorはブラウザに対して実行される自然言語テストを書ける：

login as "customer@test.com"
click on "Products"
add "Blue Widget" to cart
go to checkout
enter "SAVE20" in "Discount Code"
click "Apply"
check that "Total" decreased by 20%

コードなし。セレクターなし。XPathなし。AIが要素の見た目と機能から操作対象を判別。

最適な用途： 深い自動化の専門知識がないチーム、またはビジネスステークホルダーにテストを読んで検証してもらいたいチーム。

mabl：エージェント型テスター

mablは別のアプローチ——アプリケーションの使用を観察し、行動からテストを生成。ユーザーフローを一度クリックスルーすれば、mablが再利用可能で自己メンテナンスするテストを作成。

最適な用途： AIに事前定義シナリオの検証だけでなく、積極的に問題を発見してほしいチーム。

Katalon AI Assist

KatalonはAI搭載の生成で従来のテスト自動化を強化。StudioAssist機能でテストしたい内容を記述すれば、好みのフレームワークでテストスクリプトを生成。

最適な用途： すでにKatalonを使用しているチーム、または標準フレームワーク（Selenium、Appium、Playwright）でAI生成テストが欲しいチーム。

✅ 確認クイズ: testRigorとmablのどちらを選ぶべき？testRigorは自然言語で要件からテストを書きたいとき。mablはAIに実際のユーザー行動から学んで自律的に問題を発見してほしいとき。出発点が仕様かユーザーインタラクションかで選択。

テスト生成のための効果的なプロンプト

AIテスト生成は入力の質で決まる。包括的なテストケースを得るためのフレームワーク：

RBCEフレームワーク

R — Requirements（要件）： 機能が何をするかを正確に記述。 B — Boundaries（境界）： 制限、最小値、最大値、閾値を定義。 C — Constraints（制約）： ビジネスルール、依存関係、前提条件をリスト。 E — Exceptions（例外）： 問題発生時に何が起こるべきかを記述。

弱い入力：

ログインページをテストして。

強い入力（RBCE）：

要件: メールとパスワードでログイン。
境界: メール最大254文字。パスワード8-128文字。
制約: 5回失敗でアカウントロック（30分間）。
  管理者アカウントは二要素認証必須。セッションは2時間で期限切れ。
例外: 「認証情報が無効です」と表示（どのフィールドが間違っているかは表示しない——セキュリティ）。
  「アカウントロック中」とロック解除時刻を表示。SSO リダイレクト失敗を処理。

弱い入力は3〜5の基本テスト。強い入力はセキュリティ、エッジケース、エラーハンドリングをカバーする20〜30のテストを生成。

生成から実行へ

AI生成テストは完成品ではない——初稿だ。効果的なワークフロー：

1. 生成： 要件をAIに入力 → テストケースを取得
2. レビュー： QAエンジニアがドメイン固有のギャップを確認
3. 補強： AIが見逃したシナリオを追加（複雑なビジネスロジック、システム間ワークフロー）
4. 優先順位付け： スモーク/リグレッション/ディープにタグ付け（AIもこれを支援）
5. 実行： CI/CDパイプラインで実行
6. 保守： アプリが変わるとAIがテストを更新（レッスン4で詳しく）

人間の仕事は「すべてのテストをゼロから書く」から「レビュー、補強、検証」にシフト——速く、退屈が少なく、より良い結果を生む。

まとめ

• AIは自然言語の要件からテストケースを数日ではなく数分で生成する
• RBCEフレームワーク（要件、境界、制約、例外）が最も包括的なテストスイートを生み出す
• testRigorは自然言語、mablはユーザー行動から学習、KatalonはAI支援でスクリプト生成
• AI生成テストは必要なテストの60〜80%をカバー——人間のレビューがドメイン固有シナリオを追加して本番品質に
• ワークフローは「すべてを書く」から「生成、レビュー、補強、優先順位付け」にシフト

次のレッスン

次は「AIコードレビュー実践」——開発サイクルで修正コストが最も安い段階で、コードがQA環境に届く前にバグをキャッチする方法を学びます。