test-guide-from-code

手動テストガイドの生成

コードの変更内容から、構造化された手動テストガイドを自動生成し、テスターが変更された機能を正確に検証できるようにします。

入力形式、出力テンプレート、例については、reference.md を参照してください。

トリガー

• 「テストガイドを生成」「テストガイド」「手動テストガイド」「テスト手順」
• 「test guide」
• 「コードからテストを生成」「コードからテストガイドを生成」
• 「MR からテストガイドを生成」「PR からテストガイドを生成」
• 引数に対応しています：「テストガイドを生成：https://gitlab.example.com/merge_requests/123」

使用するタイミング

• MR／PR の提出後、テスター向けの検証ガイドを提供する場合
• リリース前に、コードの変更内容に基づいて手動回帰テストの範囲をまとめる場合
• 機能の受け入れ確認時に、コードの変更内容からテスト可能なユーザー操作を導き出す場合

実行フロー

ステップ 1：変更内容の取得

1. 入力の種類を検出し（reference.md の入力形式の表を参照）、適切な取得方法を選択します
2. URL の場合：まず CLI で diff の取得を試みます。失敗した場合は、ユーザーに貼り付けを依頼します
3. 入力がない場合：git diff（作業ツリー）または git diff HEAD~1（最新のコミット）を使用します
4. 有効な diff を取得できたことを確認します

ステップ 2：変更内容の分析

1. 変更ファイル一覧：機能モジュールごとに分類します
2. 変更種別の分類：🆕 追加／🔄 変更／🐛 修正／⚙️ 設定／🗑️ 削除
3. ユーザーが認識できる動作の変更：ユーザーやシステムの動作への影響を推測します
4. 暗黙的な変更の特定：設定ファイル、依存関係のアップグレード、データベースのマイグレーション、API コントラクトの変更

ステップ 3：テストガイドの生成

各テスト項目には、テストの目的、前提条件、テスト手順（開発者以外にもわかりやすい内容）、期待結果、優先度を含めます。

優先度：P0 コア業務／データ書き込み／セキュリティ → P1 補助機能／UI／パフォーマンス → P2 スタイル／文言／内部リファクタリング

変更種別 → テスト戦略：

• 🆕 → 正常系 + 境界値／エッジケース
• 🔄 → 変更点の検証 + 既存機能の回帰テスト
• 🐛 → バグ発生条件の検証 + 関連機能の回帰テスト
• ⚙️ → 設定の有効性 + 影響を受ける機能の回帰テスト
• 🗑️ → 削除の確認 + 関連機能への影響がないことの検証

ステップ 4：回帰検証の補足

変更されたモジュールから関連モジュールを導き出し、回帰テストが必要な機能と検証方法を列挙します。

ステップ 5：出力

reference.md のテンプレート形式を使用してテストガイドを生成し、デフォルトでは現在の作業ディレクトリに Markdown ファイルとして保存します。

ファイル名：<feature>_manual_test_guide_<YYYY-MM-DD>.md（命名規則と例については、reference.md の「ファイル名の規則」を参照してください）

ユーザーによる上書き指定：ユーザーは、トリガー時に任意のパスまたはファイル名を指定できます。指定された場所に保存します。

会話での出力：内容全体を繰り返さず、保存先、テスト項目の統計（P0／P1／P2 の内訳）、主な変更点 3～5 件、回帰テストの範囲のみを簡潔に出力します。すべてのテスト項目はファイルにのみ記載します（方針については、reference.md の「会話での出力方針」を参照してください）。

注意事項

• ❌ 暗黙的な変更の特定を省略し、業務コードだけを分析する
• ❌ テスト手順に開発者向けの用語（「API を呼び出す」「200 を返す」など）を使う
• ❌ バグ修正で、元のバグ発生条件を見落とす
• ❌ 自動テストを手動テストガイドに混在させる
• ❌ 回帰検証の範囲を考慮しない
• ❌ diff を取得できていないのに、テスト項目を作り出す
• ❌ 現在の作業ディレクトリを確認せずにファイルを書き込み、誤った場所に保存する
• ❌ ファイル名にスペースやファイルシステムで使用できない特殊文字（/ \ : * ? " < > |）を含める
• ❌ ファイル生成後、会話で保存先のフルパスを報告しない