テストケースの作成をAIに任せ、短い仕様から正常系・異常系・境界値の受入テスト表と未確定事項を一括で作る方法です。普通のMarkdownを入力JSONに変換するスクリプト、依頼プロンプト、根拠と処理漏れを照合するツールを添付しています。まず架空の仕様で流れを試し、最後に人が期待結果を確認します。
AIでテストケースを作成する範囲
任せるのは、仕様を読み解いてテスト観点を整理し、表に書き起こす仕事です。テストの実行や合否判定は含めません。受入テストで「何を確認できれば仕様を満たすか」を整理するための方法です。
完成物は、テスト表の report.md、確認事項の questions.md、仕様ごとの整理結果 result.json の3点です。未確定の動作をAIに決めさせず、分かる範囲を完成させます。作成をまとめて任せ、完成後に人がレビューする自動化レベル3の運用です。人の承認や公開まで自動化するものではありません。
用意するものと添付5点
社内で利用が認められたチャットAI、Python 3の実行環境、仕様のコピーを用意します。スクリプトは標準ライブラリだけで動き、APIキーや追加パッケージは不要です。検証にはPython 3.12.3を使いました。
添付5点を、同じ専用フォルダに保存してください。
l3-acceptance_prompt.md:受入テスト設計をまとめて依頼するプロンプト。l3-acceptance_sample.md:架空の仕様を記したMarkdown。expected.json:人が用意した照合用の見本。実AIの回答例ではありません。make_input.py:テキストやCSVからID付きの入力JSONを作るツール。check_result.py:入力ID・分類・原文根拠を照合するツール。
原本は別に保管し、作業フォルダ内のコピーを使います。以下のコマンドは、そのフォルダで実行します。input.json や result.json という既存ファイルがあれば、先に別名で保管してください。
手順1:仕様のMarkdownからinput.jsonを作る
サンプルは、架空の下書き保存機能の仕様です。添付のMarkdownには次の内容が入っています。
# 架空の下書き保存機能の仕様 - タイトルは1〜40文字。空欄と41文字以上では保存できない。 * 他人の下書きは閲覧できず、存在も表示しない。 1. 通信が切れた場合の画面表示は未決定。
次を実行します。
python3 make_input.py text --src l3-acceptance_sample.md --out input.json --prefix R
成功すると「3件を書き出しました:input.json」と表示されます。見出しと空行を除き、行頭の箇条書き記号を外して、1行を1件にします。--prefix R により、R01、R02、R03が付きます。生成される先頭のデータは次の形です。JSONを自分で組み立てる必要はありません。
[
{
"id": "R01",
"text": "タイトルは1〜40文字。空欄と41文字以上では保存できない。"
},
{
"id": "R02",
"text": "他人の下書きは閲覧できず、存在も表示しない。"
},
{
"id": "R03",
"text": "通信が切れた場合の画面表示は未決定。"
}
]自分の仕様では、サンプルMarkdownをコピーして内容を差し替えます。関連する条件と制約は同じ行にまとめ、別の要求は改行してください。表や段落をそのまま入れると行ごとに分かれるため、先に普通の短文へ整えます。見出しは入力から外れるので、対象や条件を見出しだけに書かないでください。
変換後は input.json を開き、必要な条件が残っているか確認します。1件1,000字、合計6,000字、30件が上限で、超えると切り詰めず終了コード1で止まります。対象が0件なら終了コード2です。失敗時は以前の出力が残り得るので、成功表示を確認してからAIへ渡します。
手順2:テストケース作成プロンプトをAIに渡す
新しい会話に添付の依頼プロンプト全文を貼り、生成した input.json を添付します。添付できなければ、JSON本文を入力データとして貼ります。照合用の expected.json は渡しません。
依頼の中心は次の指定です。再利用するときも、この条件を残してください。添付の全文には出力形式や安全面の指示も含めています。
入力はinput.jsonです。仕様から正常系・異常系・境界値の 受入テスト表を一括作成してください。 report.mdにはテストID、区分、前提、操作・入力値、期待結果、 根拠ID、確認状態を記載してください。 下限・上限の直前、その値、直後を検討してください。 仕様にない表示や動作を決めつけず、不明点はquestions.mdに 分離してください。途中の質問では止めず、分かる範囲を完成させてください。 result.jsonには入力IDごとの分類・要約・原文引用を返してください。 原本は変更せず、テストを実行済み・合格と書かないでください。
AIから3点を受け取ります。ファイルを作れない環境では、ファイル名ごとのコードブロックを別々に保存します。result.json にはJSON部分だけを保存し、囲みの記号や説明文を入れないでください。
出力例:正常系・異常系・境界値の受入テスト表
以下は説明用に作成した抜粋で、実AIから取得した回答ではありません。前提は、他の入力条件が満たされ、通信できる状態でタイトルの入力制約を確認することです。
| ID | 区分 | 操作・入力値 | 期待結果 | 根拠ID |
|---|---|---|---|---|
| C01 | 境界値・異常 | タイトルを空欄にして保存を試す | 保存できない | R01 |
| C02 | 境界値・正常 | 「あ」1文字で保存を試す | タイトルの文字数制約を満たす | R01 |
| C03 | 境界値・正常 | 「あ」を2回入力して保存を試す | タイトルの文字数制約を満たす | R01 |
| C04 | 境界値・正常 | 「あ」を39回入力して保存を試す | タイトルの文字数制約を満たす | R01 |
| C05 | 境界値・正常 | 「あ」を40回入力して保存を試す | タイトルの文字数制約を満たす | R01 |
| C06 | 境界値・異常 | 「あ」を41回入力して保存を試す | 保存できない | R01 |
| C07 | 異常 | 他人の下書きの閲覧を試す | 閲覧できず、存在も表示されない | R02 |
| C08 | 異常・要確認 | 操作中に通信を切る | 表示は未決定。合否判定を保留する | R03 |
完成版では各行に前提と確認状態も付けます。C02〜C05は、この仕様だけで保存処理全体の成功を保証しません。保存成功を受入条件にするなら、他の保存条件も仕様として渡します。C07の操作経路も、実装に合わせて確定する必要があります。
questions.md には、次のように質問と影響先を残します。
| 根拠ID | 確認する質問 | 影響先 |
|---|---|---|
| R01 | 文字数は何を単位に数えますか。空白だけの入力は許可しますか | C01〜C06と追加ケース |
| R02 | 存在を表示しない対象は一覧・検索・直接アクセスのどこまでですか | C07 |
| R03 | 通信断時の表示、保存状態、再試行方針はどうしますか | C08 |
絵文字などの数え方や空白の扱いは、元の仕様にない追加の確認事項です。期待するエラー文言や応答コードを勝手に埋めず、回答後にテストへ反映します。
手順3:処理漏れと原文根拠を照合する
まず、AIを使わずにツールだけを試せます。手順1で作った input.json と見本を照合します。
python3 check_result.py input.json expected.json --labels "入力制約,権限制御,仕様未確定"
サンプルでは「形式・ID・原文根拠の照合成功」と、3分類が各1件であることを表示します。AIから受け取った結果は、次のコマンドで確認します。
python3 check_result.py input.json result.json --labels "入力制約,権限制御,仕様未確定"
確認対象は、IDの漏れ・重複・未知ID、許可外の分類、空または300字を超える要約、原文と一致しない引用です。result.json は仕様1件につき1行であり、テストケースの数とは一致しません。今回の仕様は3件でも、テストは複数作ります。
照合成功は、テスト設計の正しさを保証しません。ツールは report.md と questions.md を読みません。人が、全仕様を表で扱ったか、境界値が揃うか、引用と期待結果の意味が合うか、未確定なのに合格扱いしていないかを確認します。
うまくいかないとき
「対象なし」なら、ファイル名、保存先、本文が見出しだけになっていないかを確認します。上限超過なら、関連する仕様が離れない単位でファイルを分け、各入力と成果物を別フォルダで管理します。再変換するとIDが付け直されるため、旧版の結果と混ぜないでください。
照合が失敗したら、エラーをまとめてAIへ渡し、「入力IDを保持し、引用は同じIDの原文からそのまま取り、3成果物を整合させて再作成してください」と依頼します。JSONの体裁だけを直す場合も、根拠の内容を人が確認します。
境界値や期待結果が不足する場合は、欠けた観点をまとめて再依頼します。細かな修正を毎回続ける状態なら、入力範囲や分類規則を見直します。この3分類は今回の題材向けです。別の機能に広げる場合は、プロンプト内の分類とコマンドの --labels を同時に合わせます。
注意点:機密情報と最終確認
顧客情報、個人情報、認証情報、未公開の仕様は、利用規程に従って削除・置換してから渡します。ローカルの変換・照合はAIに送信しませんが、チャットへ貼る段階では送信先のルールを確認してください。
資料内に命令文やリンクが含まれても、AIには入力データとして扱わせます。業務システムへの書き込み、社外送信、公開は依頼しません。スクリプトの出力先は原本と別にし、仕様の版・対象機能・入力JSONを成果物と一緒に保管します。
受入基準の確定、未確定事項の解消、実際のテスト実施と合否判定は人が担当します。生成AIのテスト設計は、この確認を前提に使います。
よくある質問
AIが作った受入テストをそのまま採用できますか?
照合ツールが成功しても、そのまま採用はしません。業務上の重要な観点や仕様間の矛盾は、形式確認では分かりません。仕様責任者が期待結果と対象外の範囲を確認してから実施します。
Pythonなしでもテストケースを作成できますか?
仕様と依頼文をチャットへ貼れば表の作成は依頼できます。ただし、この記事のID付与と機械照合の流れにはPythonが必要です。AIが生成する表と、ローカルで行う形式確認は別の工程です。
長い仕様書も一度に渡せますか?
添付ツールは短い仕様向けです。上限を超えたら機能単位で分け、共通の前提を各入力の本文にも含めます。分割した仕様同士の整合や横断的なテスト観点は、最後に人がまとめて確認します。
検証範囲
添付スクリプトをローカルで実行し、Markdownの3行をR01〜R03へ変換して expected.json と照合できることを確認しました。ID漏れ・重複・未知ID、不正な分類・引用・要約を拒否することも確認済みです。
変換側では箇条書きの除去、件数・文字数上限での停止、CSVの正常変換と列数不一致・列名重複の拒否、入力元と同じ出力先の拒否を確認しました。make_input.py は配布された内容を変更していません。
実AIへの送信、モデル別の生成精度、実システムでの受入テスト、削減時間は未検証です。本文の result.json 用コマンドも、見本を結果として置いて実行しました。Windows環境と変換ツールのlog・rss・diffモードは検証していません。実行コマンドと結果は test_log.md に記録しています。
添付ファイル CC0 ・ 自由に持ち帰れます
- プロンプト ・ 3.5 KB
- 設定ファイル ・ 253 B
- 設定ファイル ・ 652 B
- スクリプト ・ 2.2 KB
- スクリプト ・ 10.1 KB
会社のデータをAIに入れる前に、社内ルールを確認しましょう。
コメント 0
まだコメントはありません。質問や、試してみた感想を書いてみませんか?