テストケース用プロンプト：要件を貼るだけで、正常・境界・異常ケースを一度に表で返す

テストケース用プロンプトが担うのは、要件レビューの後で一番時間のかかる工程です。機能は全員理解しているのに、いざケースを書き始めると、正常系はスラスラ進み、境界値と異常系が数件抜け落ち、引き渡し後の欠陥票で補うことになります。以下のプロンプトは、ケースの分類、表の列、期待結果の書き方を先に固定してから要件を貼る形にしてあるため、返ってくるのはそのまま実行でき、ケース管理ツールにも取り込める表です。

このプロンプトが向いている場面

新機能の引き渡し前にケースを補うとき、改修後の回帰リストを作り直すとき、企画担当が受け入れ基準を自分で確認するときに使えます。前提として、はっきり書かれた要件の一節が必要です。プロトタイプの説明、要件文書の一段落、ユーザーストーリーでも構いません。口頭の一言しかない場合は、背景、入口、ルール、制限を短い文章に直してから貼ってください。出力の質が大きく変わります。

そのまま使えるプロンプト

あなたは経験 8 年のソフトウェアテストエンジニアです。以下の要件をもとに、そのまま実行できるテストケースを設計してください。

要件：{{要件}}
補足情報：{{補足情報。関係する画面や API、アカウントの役割、データの制限など。なければ「なし」と書く}}

出力ルール：
1. 表で出力し、列はケース番号、ケース名、前提条件、手順、テストデータ、期待結果、優先度、ケース種別の順にする。
2. ケース種別は、正常系、境界値、異常・エラー、権限と役割の 4 種類を必ず含め、各種別に最低 3 件出す。
3. 境界値は具体的な数値で書く。文字数上限、金額上限、送信回数上限など、「最大値を入力」のような書き方はしない。
4. 期待結果は確認できる形で書く。画面の文言、データの変化、状態の変化を明示し、「正常に動作する」のような空文は書かない。
5. 表の後に「要件に書かれていて確認が要る点」という節を分け、曖昧な点を 1 件ずつ挙げる。空白を埋めるためのルールを勝手に作らない。

表を先に出力し、その後に確認点を示す。表の前に長い説明は付けない。

2 つの変数の埋め方

• {{要件}}：業務ルール、項目の制限、状態遷移を含め、要件の原文をそのまま貼ります。具体性が高いほど良い結果になります。「クーポン機能を作る」とだけ書くと、モデルは一般的な EC のルールで推測するしかなく、実際のルールと合わないケースが返ります。
• {{補足情報}}：テストで使えるものを書きます。どの役割のアカウントがあるか、既成のテストデータがあるか、機能がアプリかブラウザかといった情報です。役割の情報が特に重要で、権限系のケースはすべてここから生成されます。

埋めた後の出力例

要件を「ユーザーは配送先住所を変更できる。住所テキストは最大 100 文字、都道府県・市区町村は必須、保存後に新しい住所がすぐ反映される」という一節に置き換えると、返る表には次のような行が含まれます。

このように具体的な数値を持った行が出れば、プロンプトは効いています。ケース名がどれも「保存機能を確認する」調なら、出力ルールの 3 と 4 を強調してもう一度実行してください。

結果が物足りないときの追加指示

• ケースが浅い：「優先度が高いものだけ残し、各ケースに反対の確認を足してください。わざと間違えた入力をシステムがどう止めるかまで書くこと」と続けます。
• 連打や二重送信が抜ける：補足情報に「同じユーザーが保存を連続で押すことがある」と加え、「繰り返し操作」の種別を足すよう頼みます。
• 自動化したい：「優先度の高いケースを Playwright のテスト手順に書き換え、各手順にロケーターと検証を付けてください」と続けます。

最後に一つだけ。AI が作るケースは第一稿と漏れチェックには向きますが、支払い、権限、データ削除に関わるケースは、リリース前にテスト担当が実環境で 1 件ずつ実行してください。特に「確認が要る点」に挙がった曖昧さは、レビューの場で誰も詰め切れていなかった点であることが多いものです。