ousiass/test-plan

Test Plan Generator

PRのbodyに書かれたTest planチェックリストを読み取り、PRの差分とリポジトリ構成を分析して、ローカル環境での具体的なテスト実行手順書を生成し、PRコメントとして投稿する。

対象読者: 非エンジニアを含む全メンバー。 専門用語を避け、コマンドはコピペで完結させ、操作は「どこをクリックして何が表示されればOK」のレベルで書く。

引数

• 第1引数: PR番号（必須）
• 第2引数: owner/repo（任意、省略時はカレントリポジトリ）

例: /test-plan 176, /test-plan 176 NonEntropyJapan/Kaikei-Support

ワークフロー

Phase 1: 情報収集

以下を並列で取得する:

1. PR情報: gh pr view <番号> --json title,body,files,baseRefName,headRefName
2. PR差分: gh pr diff <番号>
3. リポジトリ構成: ルートディレクトリの内容を確認

第2引数がある場合は各 gh コマンドに --repo <owner/repo> を付与する。

Phase 2: 解析

2a. テスト項目の抽出

PRのbodyからTest planセクション（表記揺れを許容）を探し、チェックリストを抽出する。

• - [ ] 未完了項目 → 手順書の対象
• - [x] 完了済み項目 → 「自動テストで確認済み」と1行で記載し、手順は省略

チェックリストが見つからない場合はユーザーに報告して終了。

2b. 環境起動方法の特定

リポジトリ構成とPR差分から、ローカル起動方法を判定する。主な手がかり:

1. docker-compose.yml / compose.yml がある → docker compose up -d
2. supabase/ ディレクトリがある → supabase start
3. Makefile がある → Makefileの内容を確認してdev/start系ターゲットを探す
4. package.json の scripts を確認 → npm run dev 等

backend / frontend が分離している場合はそれぞれの起動方法を記載する。

2c. 環境変数の特定

PR差分に .env.example や環境変数の追加・変更がある場合、新規に必要な環境変数をリストアップする。

2d. テスト手順の生成

各テスト項目について、PR差分の関連コードを読み、以下を生成:

• 手順: 番号付きステップで具体的な操作を記述
  • APIエンドポイントの変更 → curl コマンドやHTTPリクエスト例
  • UI変更 → ブラウザでの操作手順
  • Webhook/外部連携 → テスト用リクエストの送り方
• 確認ポイント: 何が起きれば成功か
• 関連ファイル: 差分の中で該当するファイルパス

変換の例:

| テスト項目 | 差分から読み取れること | 生成する手順 | |---|---|---| | 承認依頼 → ボタン付きメッセージ送信確認 | lib/slack.ts で chat.postMessage + Block Kit、routes/workflows/submit.ts でワークフロー提出時に通知 | 1. フロントから経費申請を提出（http://localhost:3000）<br>2. Slackチャンネルを確認<br>確認: ✅承認 / ❌却下 ボタン付きメッセージが届く | | ボタン押下 → 承認処理 → メッセージ更新確認 | routes/slack/interactions.ts で action_id を処理、SlackユーザーID → 従業員特定 → WorkflowApproval作成 | 1. Slackで✅承認ボタンをクリック<br>2. DBの WorkflowApproval テーブルを確認<br>確認: メッセージが「承認済み」に更新される |

Phase 3: 手順書の組み立て

以下のフォーマットで手順書を組み立てる。

書き方のルール

• 専門用語は使わない。 やむを得ず使う場合は直後にカッコで補足する
  • 悪い例: supabase start でローカルDBを起動
  • 良い例: supabase start（データベースをPC上で起動するコマンド）
• コマンドはコピペで完結させる。 「<YOUR_TOKEN> を置き換えてください」のような穴埋めが必要な場合は、何をどこで取得するかを具体的に書く
  • 悪い例: SLACK_BOT_TOKEN=<your-token>
  • 良い例: SLACK_BOT_TOKEN=ここにトークンを貼り付け（取得方法: Slack管理画面 → OAuth & Permissions → Bot User OAuth Token をコピー）
• 操作は「どこを → どうする → 何が起きる」の3点セットで書く
  • 悪い例: 承認依頼を送信して確認
  • 良い例: 画面左の「経費申請」メニューをクリック → 金額に「1000」と入力して「送信」ボタンを押す → 「申請を受け付けました」と表示される
• 成功/失敗を明確に書く。 「問題なければOK」は禁止。具体的に何が見えれば成功かを書く
  • 悪い例: メッセージが届くことを確認
  • 良い例: Slackの #approval チャンネルに「承認依頼: 経費申請 ¥1,000」というメッセージが届き、「✅承認」「❌却下」の2つのボタンが表示されていればOK
• 困ったときの対処も書く。 各ステップで「うまくいかない場合」のヒントを添える
  • 例: ※ 画面が表示されない場合 → ターミナルに戻り、エラーメッセージが出ていないか確認してください

出力テンプレート

## テスト手順書

> PR: #<番号> <タイトル>

### 準備するもの
- <必要なツール（インストール手順のリンク付き）>

### 事前準備: 環境変数の設定
<新規に必要な環境変数がある場合のみ。取得場所と設定方法をステップで記載>

### 手順1: アプリをPC上で起動する

<判定した起動手順。各コマンドに「何をしているか」の説明を添える>

※ うまくいかない場合 → <よくあるトラブルと対処>

---

### テスト項目

#### テスト1: <テスト項目名>
**やること:**
1. <どこを> → <どうする>
2. ...

**成功の目安:** <具体的に何が見えればOK>

※ うまくいかない場合 → <ヒント>

#### テスト2: <テスト項目名>
...

---

### 自動テスト（開発者向け）
<テストコマンドがある場合。非エンジニアはスキップ可と明記>

### 後片付け: アプリを停止する
<停止コマンドと「何をしているか」の説明>

Phase 4: 投稿

生成した手順書を gh pr comment <番号> --body "..." でPRコメントとして投稿する。確認は不要、そのまま投稿してよい。

注意事項

• テスト項目が外部サービス連携（Slack, 決済等）を含む場合、モックやテスト環境での代替手段を提案
• 手順書は実行者がコードを読まなくても手順通りに進められるレベルの具体性を目指す
• 差分が大きい場合はAgentツールを使って並列に解析する