AIに「テスト観点を出して」と頼むと、それらしい一覧が返ってくることがあります。ただ、読みやすくまとまっていても、実際の仕様にはない条件が混ざっているかもしれません。この記事では、架空のログイン機能を使って、AIへの頼み方と出力の確認方法を説明します。根拠が見つからない提案を、担当者への質問に変える例も載せています。
この記事のポイント
AIが出した観点は、確認してから使います。仕様に書かれていること、AIからの提案、まだ確認が必要なことを分けてください。期待結果の根拠を人が確認できたら、具体的なテストケースにします。
この記事で使う資料
登録不要でダウンロードできます。サンプルはすべて架空のデータです。
対象の機能、仕様、確認したいリスクを用意する
まずは一つの機能を選ぶと、出力を確認しやすくなります。対象のユーザー、どこまでの操作を確認するか、参照する仕様と版、特に避けたい不具合を短くまとめます。仕様がない箇所は「未定義」と書いておきます。
ここで使うR1〜R4は、記事用に作った架空の仕様です。実務で使うときは、利用を認められた資料だけを渡し、認証情報や顧客データは含めないようにしてください。使うAIが、渡した資料の内容を読める環境かどうかも確認します。
以下は記事用に作成した架空のログイン仕様です。
R1：登録済み・利用可能な一般ユーザーは、正しいメールアドレスとパスワードでログインできる。
R2：成功後はマイページへ遷移し、そのユーザーの表示名を表示する。
R3：メールアドレスまたはパスワードが空欄なら、空欄の項目に「入力してください」と表示し、ログインしない。
R4：メールアドレスとパスワードが両方入力されていて、認証情報が一致しない場合は「メールアドレスまたはパスワードが正しくありません」と表示し、ログインしない。
未定義：失敗回数によるロック、パスワードの長さ、利用停止ユーザー、二要素認証。プロンプトをコピーして試してみる
そのまま練習できるように、プロンプトには架空の仕様も入れています。自分の案件で使うときは、目的と仕様に加えて、参照先と版も置き換えてください。依頼文の一例なので、使うAIによって回答や動作は変わります。
以下の仕様だけを根拠に、テスト観点のたたき台を作成してください。
目的：正しくログインでき、失敗時にはログイン状態にならないことを確認する。
対象・資料の版：記事用の架空ログイン仕様 R1〜R4
以下は記事用に作成した架空のログイン仕様です。
R1：登録済み・利用可能な一般ユーザーは、正しいメールアドレスとパスワードでログインできる。
R2：成功後はマイページへ遷移し、そのユーザーの表示名を表示する。
R3：メールアドレスまたはパスワードが空欄なら、空欄の項目に「入力してください」と表示し、ログインしない。
R4：メールアドレスとパスワードが両方入力されていて、認証情報が一致しない場合は「メールアドレスまたはパスワードが正しくありません」と表示し、ログインしない。
未定義：失敗回数によるロック、パスワードの長さ、利用停止ユーザー、二要素認証。
分類：正常系、異常系、境界値、権限、状態遷移、利用者への影響。
出力列：ID／分類／確認目的／前提条件／操作・入力／期待結果／根拠の仕様ID／不明点。
制約：
- 仕様にない数値、エラー文言、権限を作らない。
- 確認できる事実、提案、要確認を分ける。
- 根拠がない期待結果は「要確認」とし、確定しない。
- 各分類を無理に埋めず、同じ確認を重複させない。
- 不明点は、担当者へ確認する具体的な質問として最後にまとめる。
- ファイルの変更やテスト実行は行わない。
実務で使う場合は、目的・対象・仕様・参照先・版を自分の案件に置き換えてから依頼する。出力例で、仕様から判断できることを確認する
次の表は、出力を確認する練習用に作った例です。AIを実行して得た検証記録ではありません。仕様から判断できる行と、まだ確認が必要な行を分けて読んでみてください。
| 分類・確認目的 | 条件と操作 | 期待結果／根拠 |
|---|---|---|
| 正常系：本人のマイページへ入る | 利用可能な一般ユーザー・ログアウト状態。正しい認証情報を入力して送信。 | マイページへ遷移し本人の表示名を表示／R1・R2 |
| 異常系：メール空欄を扱う | ログアウト状態。メール空欄、指定パスワードで送信。 | メール欄に「入力してください」。ログインしない／R3 |
| 異常系：認証の不一致を扱う | ログアウト状態。登録済みメールと誤ったパスワードで送信。 | 定義された認証エラーを表示。ログインしない／R4 |
| 境界値：パスワード長 | 許容する長さの定義が必要。入力条件は未確定。 | 要確認。上限・下限が仕様にないため決めない。 |
| 権限・状態：利用停止ユーザー | 利用停止時の扱いを担当者へ確認する。 | 要確認。R1の「利用可能」と同じ動作だと推測しない。 |
仕様にない提案は、担当者への質問にする
たとえば「5回失敗すると30分ロックされる」という観点が出ても、R1〜R4にはその記載がありません。ほかのサービスにある機能でも、今回の仕様で決まっているとは限りません。「8文字未満はエラー」という提案も、長さの定義を確認するまでは期待結果に書けません。
こうした提案は、担当者への質問にすると使えます。回答をもらったら、根拠になる仕様IDや資料の版を記録し、テストケースに反映します。
| 根拠のない記載 | 担当者へ確認する質問 |
|---|---|
| 5回失敗で30分ロック | 失敗回数の制限はありますか。ある場合、回数・解除条件・表示はどこに定義されていますか。 |
| パスワードは8〜64文字 | 入力可能な長さと文字の数え方は何ですか。登録時とログイン時で扱いは同じですか。 |
| 管理者は別画面へ遷移 | 対象ユーザーは一般ユーザーだけですか。権限で遷移先が変わる場合、その仕様を教えてください。 |
採用する観点と、修正・確認が必要な観点を記録する
参照先が書かれていても、その内容まで合っているとは限りません。実際に開いて、期待結果の根拠になる記載があるかを確認してください。コードを調べた場合も、処理があることに加えて、対象の環境や権限でその処理を使えるかを確認します。
冒頭のCSVには、観点ID、仕様の根拠、レビューの判断、修正内容、質問先、確認者と確認日を記録できます。ここでの「採用」は、その観点をテスト設計に使うという意味です。実行して合格したという意味ではありません。
- 参照先が実際にあり、期待結果の根拠になる内容が書かれているか。
- 仕様で確認できることと、AIからの提案が分かれているか。
- 前提条件、操作・入力、確認する結果がそろっているか。
- メール空欄とパスワード空欄など、異なる条件の漏れがないか。
- 失敗後の状態、権限、利用者への影響を確認したか。不明なら質問にしたか。
- 重複や対象外の観点がないか。確認が必要な項目は、誰に質問するか決まっているか。
確認できた観点をテストケースにする
仕様の根拠を確認できたら、テストデータ、操作する順番、期待結果を具体的に書いてケースにします。まだ確認できていない観点は別に残し、仕様がわかってから追加します。最後に実際の環境でテストして、結果を記録してください。
人が直したところは、次に使うプロンプトを見直す材料になります。根拠のない数値があった、同じケースが重複していた、前提条件が抜けていた、といった内容を短く記録しておくと、依頼に何を足すか、人がどこを確認するかを考えやすくなります。