🍀この記事はこんな方におすすめ
- チームの定期作業を効率化したいQAエンジニア・品質管理担当者
- AI技術を実務に活用したい方
- テスト設計を効率化させたいQAエンジニアの方
注釈: 本記事で使用しているストーリーや具体例は、説明のための一般的なサンプルです。
はじめに
こんにちは！普段はQAエンジニアとして品質管理業務を担当しています。
ソフトウェア開発において、要件定義からテスト設計までの工程は多くの時間と労力を必要とします。特に以下のような課題がよく発生します：
- 実例マッピング（Example Mapping）で決まったルールが、画面仕様書やテスト項目書に漏れなく反映されているか確認が大変
- ドキュメント間のトレーサビリティを維持するのが難しい
- テストケースの抽出が属人化し、品質にばらつきが出る
本記事では、AIを活用して実例マッピングの結果からテスト項目書・ディシジョンテーブルまでを一貫して生成するワークフローを紹介します。
実例マッピング（Example Mapping）とは
実例マッピングは、アジャイル開発で広く使われる協調的な仕様策定手法です。
構成要素
| 要素 | 色 | 説明 |
|---|---|---|
| ストーリー | 黄色 | 実現したい機能の概要 |
| ルール | 青色 | 決定された仕様や制約 |
| 具体例 | 緑色 | ルールを説明する具体的なシナリオ（Given-When-Then形式） |
| 疑問点 | 赤色 | 議論された疑問や未解決の課題 |
実例マッピングの出力例
注釈: 以下は説明のためのサンプルストーリーです。
ストーリー: ユーザーはパスワードをリセットできる
ルール:
- リセットリンクの有効期限は30分とする
- 過去に使用したパスワードは再利用不可
- パスワードは8文字以上、大文字・小文字・数字を含む
具体例:
- 登録済みメールアドレスを入力 → リセットリンクが送信される
- 30分以内にリンクをクリック → パスワード再設定画面に遷移
- 新しいパスワードを入力 → パスワード変更完了
疑問点:
- 存在しないメールアドレスの場合どうするか？
→ セキュリティ上、エラーも表示しない
ワークフローの全体像
各ステップの詳細
ステップ1: DesignDoc作成
目的: 実例マッピングで議論された内容から、決定事項（ルール）のみを抽出し、構造化する
抽出するもの:
- 決定された仕様や制約（発行者名は削除）
- カテゴリごとに整理
抽出しないもの:
- 疑問点として議論中の項目（別セクションで参考として記載）
- 具体例（テストケースで管理）
出力例:
注釈: 以下は説明のためのサンプルです。
# パスワードリセット - Design Document
## 決定事項（ルール）
### 1. リセットリンクの管理
- **リセットリンクの有効期限は30分とする**
- **リンクは一度使用したら無効になる**
### 2. パスワードバリデーション
- **8文字以上、大文字・小文字・数字を含む**
- **過去に使用したパスワードは再利用不可**
### 3. セキュリティ
- **存在しないメールアドレスでもエラーを表示しない**
- **3回連続失敗でアカウントロック**
## 未解決の疑問点（参考）
1. アカウントロック解除の方法
→ 別途サポートフローで検討
ステップ2: 画面仕様書作成
目的: DesignDocとワイヤーフレームを基に、実装可能な画面仕様書を生成
含めるセクション:
| セクション | 内容 |
|---|---|
| 概要 | 画面の目的、対象ユーザー、前提条件 |
| 画面遷移フロー | 遷移元、遷移先、遷移図 |
| 画面要素詳細 | 表示要素、バリデーション、動作仕様（表形式） |
| データ仕様 | 入力データ、保存データ |
| API仕様 | エンドポイント、リクエスト/レスポンス（JSON例付き） |
| エラーハンドリング | エラーケース一覧（表形式） |
| セキュリティ要件 | 認証・認可、データ保護 |
| 実装時の注意事項 | フロントエンド/バックエンド別 |
ポイント:
- DesignDocの決定事項をすべて反映
- 未確定項目は
[TODO: xxx]で明示 - 表形式を活用して読みやすく
ステップ3: 画面仕様書レビュー
9つのレビュー観点:
| 観点 | チェック内容 |
|---|---|
| 完全性 | 必須セクションの存在、DesignDocとの整合性 |
| 正確性 | 画面遷移、データ仕様、API仕様の正確性 |
| 一貫性 | 用語、フォーマット、命名規則の統一 |
| 実装可能性 | 開発者が仕様書だけで実装できるか |
| セキュリティ | 認証・認可、データ保護、タイムアウト |
| ユーザビリティ | エラーメッセージ、ガイダンス、操作性 |
| パフォーマンス | レスポンスタイム要件 |
| テスト可能性 | テストケース抽出可能性 |
| 保守性 | ドキュメント構造、トレーサビリティ |
ステップ4: PRDとの整合性チェック
チェック項目:
- PRDの「やること（In Scope）」が画面仕様書に反映されているか
- PRDの「やらないこと（Out of Scope）」が考慮されているか
- 対象ユーザーの定義が一致しているか
- セキュリティポリシーが参照されているか
ステップ5: テスト項目書・ディシジョンテーブル作成
テスト項目の分類:
- 正常系テスト
- 準正常系テスト
- 異常系テスト
- 境界値テスト
- その他（セキュリティ、パフォーマンス、アクセシビリティ）
テストケースの抽出元:
| 抽出元 | 抽出するテスト |
|---|---|
| 画面要素 | 表示確認、操作確認 |
| バリデーション | 入力チェック、エラー表示 |
| API仕様 | リクエスト/レスポンス確認 |
| エラーハンドリング | エラーケースの網羅 |
| セキュリティ要件 | 認証、認可、タイムアウト |
暗黙的なテストケースの抽出（重要）:
画面仕様書に明示されていない以下のケースも必ず抽出：
a) 入力値の網羅性
- 最小値・最大値・境界値
- 空文字、NULL、未入力
- 全角・半角・特殊文字・絵文字
b) 状態遷移の網羅性
- 戻るボタン操作時の挙動
- ブラウザのリロード時の挙動
- セッションタイムアウト時の挙動
- 複数タブ・複数デバイスでの同時操作
c) 環境・条件の組み合わせ
- 異なるブラウザ（Chrome、Safari、Firefox、Edge）
- 異なるデバイス（PC、スマートフォン、タブレット）
- ネットワーク状態（オフライン、低速回線、途中切断）
ソース列の設定:
- 画面仕様書に明記 → 「画面仕様書」
- DesignDocに明記 → 「DesignDoc」
- 暗黙的に抽出 → 「暗黙的抽出」
成果物の紹介
注釈: 以下は説明のためのサンプルです。
テスト項目書（一部抜粋）
| テストID | テスト項目名 | テスト観点 | テスト分類 | 優先度 | ソース |
|---|---|---|---|---|---|
| TC001 | パスワードリセット画面の表示確認 | 画面表示 | 正常系テスト | High | 画面仕様書 |
| TC002 | リセットリンク送信成功 | 基本機能 | 正常系テスト | High | 画面仕様書 |
| TC010 | リセットリンク有効期限切れ（30分経過） | 認証 | 異常系テスト | High | DesignDoc |
| TC015 | 過去パスワードの再利用エラー | バリデーション | 異常系テスト | High | DesignDoc |
ディシジョンテーブル（一部抜粋）
| 因子 | 水準 | TC001 | TC010 | TC015 | TC030 |
|---|---|---|---|---|---|
| ユーザー状態 | 未ログイン | ○ | ○ | ○ | ○ |
| メールアドレス | 登録済み | ○ | ○ | ○ | - |
| リセットリンク有効期限 | 30分超過 | - | ○ | - | - |
| 新パスワード | 過去に使用済み | - | - | ○ | - |
AIを活用したポイント
1. プロンプトの構造化
各ステップで使用するプロンプトを以下の構造で統一：
# 依頼内容
[タスクの説明]
## 入力情報
[参照するドキュメント]
## 作成要件
[具体的な作成ルール]
## 出力形式
[期待する出力フォーマット]
## 注意事項
[重要なルール・制約]
2. トレーサビリティの維持
- すべてのドキュメントに「参考資料」セクションを設置
- テスト項目書の「ソース」列で出所を明示
- DesignDocの決定事項がどこに反映されているか追跡可能
3. レビューチェックリストの活用
- 観点ごとにチェック項目を定義
- 評価基準を明確化（○/△/×）
- 指摘事項を重要度別に整理
4. 暗黙知の形式知化
AIに「暗黙的なテストケース」の抽出ルールを明示的に指示：
- 入力値の網羅性
- 状態遷移の網羅性
- 環境・条件の組み合わせ
- セキュリティ観点
効果と学び
定量的な効果
| 項目 | 従来 | AIワークフロー後 |
|---|---|---|
| テストケース数 | 30〜40件（属人的） | 70件以上（網羅的） |
| ドキュメント作成時間 | 数日 | 数時間 |
| レビュー観点の網羅性 | 担当者依存 | 9観点で統一 |
| トレーサビリティ | 手動管理 | 自動追跡可能 |
学んだこと
- プロンプトは具体的に: 抽象的な指示では期待する出力が得られない
- チェックポイントを明示: 「テストケース数の一致」など具体的な確認項目を設定
- 反復的に改善: 初回の出力を見て、プロンプトを修正していく
- テンプレートの活用: CSV形式など、構造化された出力を指示する
おわりに
本記事では、実例マッピングからテスト項目書までをAIで一貫して生成するワークフローを紹介しました。
このワークフローの最大のメリットは、トレーサビリティの維持と暗黙知の形式知化です。実例マッピングで決まったルールが、最終的なテスト項目書まで漏れなく反映され、どの決定事項がどのテストケースに対応しているか追跡できます。
また、AIに明示的なルールを与えることで、「経験豊富なQAエンジニアなら考えるであろうテストケース」を網羅的に抽出できるようになりました。
観点部分に関して精度を高めていきたいので、活用して観点を追加する部分に手を加えていきたいと考えております！
付録: プロンプト集
実例マッピングからDesignDoc作成プロンプト
# 依頼内容
以下の実例マッピング結果から、決定事項（ルール）のみを抽出してDesign Documentを作成してください。
## 入力情報
### 実例マッピング結果
[実例マッピングのPDFまたはテキスト]
## 作成要件
### 抽出基準
- 明確に決定された仕様や制約を抽出する
- 発行者名は記載しない
- カテゴリごとに整理する（認証、バリデーション、セキュリティ、データ管理、UI/UXなど）
### 抽出しないもの
- 疑問点として議論中の項目（別セクションで参考として記載）
- 具体例（テストケースで管理）
## 出力形式
以下の構成でDesign Documentを作成:
1. ストーリー概要
2. 決定事項（ルール）- カテゴリ別
3. 未解決の疑問点（参考）
4. 実装時の注意事項
画面仕様書からテスト項目書作成プロンプト
# 依頼内容
以下の画面仕様書を基に、テスト項目書とディシジョンテーブルを作成してください。
## 入力情報
### 画面仕様書
[画面仕様書のファイルパス]
### DesignDoc
[DesignDocのファイルパス]
## 作成要件
### テスト項目書
#### 各テストケースに含める情報
- テストID（連番: TC001, TC002, ...）
- テスト項目名
- テスト観点
- 事前条件（Given）
- テスト手順（When）
- 期待結果（Then）
- 優先度（High/Medium/Low）
- テスト分類
- ソース（画面仕様書/DesignDoc/暗黙的抽出）
- 備考
#### 暗黙的なテストケースの抽出要件
画面仕様書に明示されていない以下のケースも必ず抽出:
a) 入力値の網羅性
- 最小値・最大値・境界値
- 空文字、NULL、未入力
b) 状態遷移の網羅性
- ブラウザのリロード時の挙動
- セッションタイムアウト時の挙動
c) 環境・条件の組み合わせ
- 異なるブラウザ、デバイス
### ディシジョンテーブル
**重要**: テスト項目書のすべてのテストケースを列として配置すること
## 注意事項
1. DesignDocの決定事項も必ずテストケースに含めること
2. 暗黙的なテストケースは必ず抽出し、ソース列と備考欄で出所を明確にすること
3. ディシジョンテーブルの列数がテスト項目書のテストケース数と一致していること
最後に、、、
株式会社COMPASSでは一緒に教育をより良くしていく仲間を募集しています。
少しでも興味を持っていただけた方は、以下よりお気軽にご応募ください。
とりあえず話をきいてみたい！という方はぜひカジュアル面談に来ていただけると幸いです。
学習eポータル＋AI型教材「Qubena（キュビナ）」を開発している株式会社COMPASSです！ 弊社に興味をお持ちいただいた方はキャリア登録をお願いします！最新情報や求人情報をお届けします！ →app.crm.i-myrefer.jp/entry/qubena/14pXH9t0sDocJgU7TD1q
Discussion