テスト仕様書の自動化
詳細は後で記録しますがとりあえず備忘録として
前提としてGeminiの利用を想定しています。
仕様書に下記をそのままコピペすればOK！
仕様書がない場合はGeminiであればソースコードを読み込ませて下記を書けばOKです！
最初から100点の答えは出ないので、その場合はもう一つのプロンプトを使ってください。
【コピペ用】テスト項目書 自動作成プロンプト
# 目的 添付の「アプリ仕様書」「バックエンド仕様書」（無ければ与えられた要件テキスト）を読み込み、プロダクト品質を担保するための**網羅的なテスト項目書**を**6列フォーマット**で作成する。 列順：**ID｜機能カテゴリ｜正常/異常｜テスト内容｜期待結果｜参照（画面/API/仕様箇所）**（タブ区切りTSVで出力） また、アップデートがしやすいようにcanvas内でアップデートを行うこと。前提と原則
- 思考プロセス：まず「全体像の把握 → 機能・データ・非同期処理の構造化 → 仕様詳細の読み込み」の順で思考し、テストの全体設計を行ってから各項目を作成する。
- 機能カテゴリ：仕様書からユーザーの利用シナリオやシステムの主要な関心事に基づいて自動抽出・命名する（末尾の「カテゴリの指針」も参照）。
- テスト粒度：個々の操作だけでなく、複数機能が連携する一連のシナリオや、ユーザー操作とバックエンド処理が競合する状況まで考慮する。
- 文章品質：一読でテスト担当者が迷わず合否判定できる具体的記述（例：「『保存しました』というトーストが3秒間表示された後、自動で消えること」）を心がける。
- 技術仕様：文字コードはUTF-8、改行はLF。IDは TC-001 からの連番で、再出力時も極力既存IDを維持する。
必須アウトプットの順番
- 仕様の要約（3–7行）：目的／主要ユースケース／アーキテクチャ上の重要点（非同期処理、外部連携など）
- 機能カテゴリ一覧（番号付き）：抽出したカテゴリ名を列挙
-
テスト項目表（TSV）：下記6列のTSVデータ
-
TSVヘッダ（この1行を先頭に出力）
ID 機能カテゴリ 正常/異常 テスト内容 期待結果 参照（画面/API/仕様箇所）
-
TSVヘッダ（この1行を先頭に出力）
作成手順（モデル向け）
Step A: 要素抽出
文書を走査し、**機能、UI挙動、データ構造、API、非同期処理（バッチ、キュー）、外部システム連携、例外処理、制約、非機能要件（性能、セキュリティ）**を全て洗い出す。
Step B: カテゴリ設計
利用者タスク、機能境界、データモデルに加え、エンドツーエンドのシナリオや**システム横断的な関心事（ネットワーク、競合など）**を考慮して機能カテゴリを設計・命名する。
Step C: 項目網羅
各カテゴリに対し、正常系 → 準正常系 → 異常系の順で、以下の観点を執拗に洗い出し、重複なく項目化する。
- 基本入出力：入力バリデーション（必須、型、桁数、境界値、禁止文字、フォーマット）、ファイル（種別、サイズ、0KB、破損）、表示（ソート、フィルタ、ページング）。
- UI/UX：ボタン（活性/非活性）、ローディング表示のタイミング、ツールチップ、エラーメッセージの内容と表示箇所、モーダル挙動、キャンセル操作。
- 状態遷移と永続化：データの作成→削除までの全状態とトリガー操作を網羅。DBフラグ更新、冪等性（二重送信防止）、データ整合性の担保。
- 非同期処理：処理のキック／実行中／成功／失敗をテスト。成功通知（メール等）、失敗時のロールバックやリトライ、部分成功、タイムアウト。
- HTTPエラー：400, 401, 403, 404, 409, 422, 429, 500 が返る代表シナリオとUI挙動。
- パフォーマンス：大容量データ（巨大ファイル・大量レコード）時の応答時間とUI反応性、高負荷時の安定性。
- セキュリティ・認可：権限外操作の防止、ID直打ちによる他人リソースアクセス、セッションタイムアウト後の挙動。
★重要★ 連携と競合
- エンドツーエンドシナリオ：主要業務フローを一気通貫で操作。
- 競合状態：複数ユーザー同時更新、ユーザー操作とバッチ処理の衝突。
- 外部連携：外部API/サービスの**正常／異常／無応答（タイムアウト）**時の挙動。
★重要★ ネットワーク問題
- オフライン/接続断：画面表示時、送信時、アップ/ダウンロード中断線の挙動。
- 不安定/低速：極端に遅い環境でのタイムアウト処理とUIフィードバック。
Step D: 採番と参照
IDは TC-001 から通し番号。参照列には後追い調査可能なように、画面名、API名、仕様書の見出しや図表番号を具体的に記載する。
Step E: 出力
- TSVデータのみを出力する（表の後に説明や補足は付けない）。
- 表の形式で出力すること
各観点の記述指針（抽象例）
カテゴリの指針
単機能だけでなく、以下のカテゴリも積極的に作成すること。
- シナリオテスト：主要業務フローを最初から最後まで通しでテスト。
- 連携・競合：外部システム連携、複数プロセス間の競合。
- ネットワーク・オフライン：通信状況に起因する問題を専門に扱う。
シナリオテストの指針
- 例：**「【正常系シナリオ】新規ユーザーが登録〜初回ログイン〜プロファイル更新〜最初の投稿〜ログアウトまで」**のように、一連の流れが分かる記述にする。
非同期処理・バッチの指針
- 成功：「〜のバッチが完了後、対象データのステータスが『完了』に更新され、完了通知メールが届くこと」
- 失敗：「〜の処理に失敗した場合、対象データのステータスが『エラー』になり、リトライ可能であること。関連データは処理前にロールバックされること」
ネットワーク・オフラインの指針
- 接続断：「【ファイルアップロード中】にネットワークを切断する」→「アップロードが中断され『ネットワーク接続が切れました』と表示。不完全なファイルはサーバに残らないこと」
- 低速：「【一覧画面】を3G回線などの低速環境で開く」→「ローディングインジケータが表示され続け、n秒でタイムアウトエラーが表示されること」
競合状態の指針
- 例：「ユーザーAとユーザーBが**【同じ記事】をほぼ同時に編集・保存する」→「先に保存した内容が正となり、後から保存しようとした側には『編集中に内容が更新されました』等の競合エラー**が表示されること（409 Conflict）」
禁止事項
- TSV表の後に説明文や追記を出力しない（貼り付け崩れ防止）
- 半角スペースでの区切りを使わない（必ずタブ）
- IDを恣意的にリセットしない（既存IDの整合性を最優先）
【コピペ用】テスト項目書 自動作成プロンプト
ありがとうございます！ ただ、この内容だと60点になってしまうので、100点を目指してさらに網羅性を高めてくれると嬉しいですもう少し手が空いたら、どんな仕様書を読み込ませて、どんな出力になったかも記録していきますね。