qa-write-test-cases

テストケース・チェックリスト生成ツール

ユーザーが提供したコンテキストから、ソフトウェアテスト用のテストケースとチェックリストを生成します。

参考資料：

• テストケースの形式 — スイート、テスト、ステップの Markdown 形式（Testomat.io に対応）
• 記述ルール — スイート、テスト、事前条件、ステップのルール、および避けるべき AI の記述パターン
• Testomat.io TMS ガイド — Testomat.io の規約と MCP ツール

前提条件

• /scan-automation-project スキルを使って、プロジェクト構造（ソースコード、E2E テスト、テストケース）を確認済みであること。
• /sync-test-cases-with-tms スキルを使って、既存の Testomat.io テストを取得済みであること。
• インタビューの手順で利用可能な場合、PLAN モードを有効にすること。

ユーザーとのやり取り

• ユーザーがテストケースを直接求めた場合でも、必ずテストケースの前にチェックリストを生成してください。
• 手順を省略しないでください。次の手順に進む前に、各段階でユーザーの承認を得てください。
• PLAN モードを強く推奨してください。最終ステップ（テストケースを md ファイルに書き込む作業）でのみ、Edit モードに切り替えてください。
• 選択肢を提示できる場合は、Ask ツールを使ってください。
• ユーザーに入力を求める際は、入力欄に候補を記入してください。
• 質問には ❓ を付け、選択肢に番号を付けてください。

❓ Do you want to:

1. action 1
2. action 2
3. type something else

ワークフロー

1. コンテキストを収集し、ソースを提示する — 承認段階
2. カバレッジの範囲を尋ねる — 承認段階
3. 対象機能のテストケースがある場合は役割を尋ねる。スモークテストでは常にスキップする
4. チェックリストを生成する — 承認段階
5. 詳細なテストケースを生成する
6. 概要を提示する

ステップ 1：コンテキストを収集する

以下を把握します。

• テスト対象の機能と、そのビジネス上の目標
• 主なテストフローとユーザージャーニー
• 懸念事項の具体的な領域

情報源：

• ユーザーのプロンプト
• タスク管理システム（Jira など）
• 要件ドキュメント（Confluence など）
• デザインモックアップ（Figma、Miro など）
• 既存のテストケース（TestRail、Testomat.io など）
• ソースコード：
  • 手動テストファイル：test-cases、tests、manual、qa、spec などのフォルダーにある .test.md または .md
  • 自動テストファイル（spec、test、cy ファイルなど）
  • プロジェクト構造

ソースは、貼り付けられたテキスト、リンク、または MCP ツールで提供される場合があります。必要に応じて、MCP の設定をユーザーに尋ねてください。

ソースコードの分析：

• 通常、このスキルはアプリケーションコードのない自動化プロジェクトで実行されます。どちらに該当するかを確認してください。
• 自動化のみのプロジェクト：簡単にスキャンし、テストファイルに重点を置いてください。
• アプリケーションと自動化の両方があるプロジェクト：アプリケーションコードを詳しくスキャンしてください。ユーザーから依頼がない限り、ユニットテストの詳細な分析は省略してください。

Testomat.io TMS の検出

Testomat.io プロジェクトかどうかを検出してください。方法は 2 つあります。

方法 1 — MCP。testomatio MCP が利用可能な場合は、以下を使ってコンテキストを収集してください。

• suites_list、suites_search — 既存の構造
• tests_search、tests_list — 既存のテスト。重複を避けてください
• steps_list、steps_search — 再利用できる共有ステップ
• tags_list、labels_list — プロジェクトの規約

方法 2 — sync-test-cases-with-tms スキル（check-tests ライブラリを使用）。pull アクションを実行し、ダウンロードされたファイルを次の点について分析してください。

• 既存の構造とスイート
• 現在のテストケース（重複を避けるため）
• プロジェクトの規約（タグ、ラベル、優先度レベル）

既存のテストケースがテスト対象の機能と重複する場合は、その旨をユーザーに伝え、テストケースの拡張または新しいスイートの作成を提案してください。

承認段階

ソースの一覧（内容は含めず、名前のみ）を提示して、次のように尋ねてください。

I've gathered information from the following sources:

- Jira issue ABC-123
- Confluence
- Figma

❓ Do you want to:

1. ➡️ Go to next step
2. ✏️ Type changes

ステップ 2：対象範囲を尋ねる

対象範囲によって最初のチェックリストの規模が決まります。ユーザーはステップ 4 で引き続き細かく調整できます。

• ステップ 1 の分析に基づいて、各段階のおおよそのテスト件数を算出します。一般的な範囲や固定の範囲は使用しないでください — 件数はテスト対象の機能に即したものでなければなりません。
• 妥当な見積もりができない場合（機能が曖昧すぎる、コンテキストが不足しているなど）は、その旨を伝え、件数を省略するか、ステップ 1 に戻ります。
• ユーザーが ✏️ その他を選んだ場合は、数値（「10 件くらい」）または自由形式の説明（「API 契約だけ、UI は不要」）を受け付け、それに応じた規模のチェックリストを作成します。

各選択肢はブロック形式で表示します。1 行目に太字のラベルとテスト件数、次の行に説明を記載します。<N> は見積もりに置き換えます。

❓ **How much coverage do you want?**

**1. 🚀 Smoke** ~<N> tests
Critical-path only

**2. ⚖️ Balanced** ~<N> tests
Happy path, key negative and common edge cases

**3. 🧨 Exhaustive** ~<N> tests
Full coverage incl. error states, boundaries, and security/perf/i18n where relevant

**4. ✏️ Other**
Type a number of tests, or describe scope in your own words

ステップ 3：ロールを尋ねる

ステップ 1 でテスト対象の機能に既存のテストケースが見つかった場合に限り、ロールを尋ねます。基本的な部分はすでにカバーされているため、ユーザーは特定の観点を希望する場合があります。

対象範囲が「スモーク」の場合も、このステップは省略します。

ユーザーがすでにロールや重点項目を指定している場合（プロンプト内、またはステップ 2 の ✏️ その他で指定した「セキュリティのエッジケース」など）は、尋ねずに該当するロールを適用します。

ロールを尋ねる場合：

• ロールを表示し（名前と簡単な説明を含む Markdown テーブル）、ユーザーに選んでもらいます。コンテキストと既存のテストケースでまだカバーされていない内容に基づいて、ロールを推奨します。
• ユーザーがロールを指定しない場合は、⚙️ デフォルトを使用します。
• ユーザーが 🔧 その他を選択した場合は、カスタムロールを定義してもらいます。
• 一部のロールのみを表示する場合は、「利用可能なロールをすべて表示」オプションを追加します。

❓ Choose role:

1. default (or recommended role based on context)
2. ☰ Show all available roles
3. ✏️ Type role name

ロール

ロール	説明
⚙️ デフォルト	バランスの取れたアプローチ
🌈 楽観派	ポジティブなフロー、正常系
🤓 こだわり派	詳細、依存関係、完璧主義
🔪 サイコ	エッジケース
🔐 ペンテスター	セキュリティ
🎨 ピカソ	UI/UX
⚖️ 弁護士	テキスト、エラーメッセージ、誤字など
🌐 多言語対応	ローカライズ、翻訳
📈 パフォーマンス	パフォーマンス、負荷、ストレスなど
🔧 その他	独自のロールを指定

ステップ 4：チェックリストを作成する

収集したコンテキストに基づいて、階層化されたカテゴリ別のチェックリストを作成します。

ステップ 2 で選択した段階に合わせて規模を調整します。

• 🚀 スモーク — 重要な経路のみ
• ⚖️ バランス — 正常系、重要な異常系、よくあるエッジケース
• 🧨 網羅的 — すべてを網羅
• ✏️ その他 — ユーザーの説明に従う

例：

- Signup
  - Signup with valid email
  - Signup with valid phone number

- Login
  - Login with valid email
  - Login with valid phone number
  - Login with invalid password

承認ゲート

• 複数選択／チェックボックスの Ask ツールが利用可能な場合：末端項目をチェックボックスとして表示し、カテゴリ名を接頭辞として付けます（例：Login: valid email）。選択した段階に推奨される項目には、あらかじめチェックを付けます。チェックされた項目がステップ 5 のテストケースになります。
• それ以外の場合：Markdown のチェックリストを表示し、項目の追加／削除／変更をユーザーに依頼します。

テストケースの件数／詳細度については、必ず尋ねます。

❓ Do you want to:

1. 👍 Keep as is
2. ➖ Less details
3. ➕ More details
4. ✏️ Type anything you want to change

• さらに詳細にする → 🤓 こだわり派ロールを有効にします。
• ユーザーがチェックリストを変更する → 再生成します（ステップ 4）。
• ユーザーが満足しない → コンテキストをさらに集めるため、ステップ 1 に戻ります。
• 承認された → ステップ 5 に進みます。

ステップ 5：詳細なテストケースを生成する

ユーザーが最初にチェックリストのみを依頼した場合は、まず「このチェックリストのテストケースを生成しますか？」と尋ねてください。

テストケースの保存先：

• 空のワークスペース、または手動テストのみのワークスペース → プロジェクトのルート
• エンドツーエンドテストのプロジェクト → test-cases/ ディレクトリ
• その他の場合 → .testeiya/test-cases/（.testeiya/ が存在し、Git の追跡対象外になっていることを確認してください）

生成ルール：

• ファイル名は feature-name.test.md にします（拡張子は必ず .test.md にしてください）。
• 複数の機能または製品全体の場合は、機能ごとに 1 つのファイルを作成します。
• ユーザーのソースコードは変更しないでください。*.test.md ファイルのみを生成してください。
• スコープを守ってください：テスト対象の機能のみをテストしてください。ユーザーから明示的に依頼されない限り、関連機能はテストしないでください。

フォーマットのルール：

• スイート、テスト、ステップについては、テストケースのフォーマットに厳密に従ってください。例外は、ユーザーがプロンプトで独自のフォーマットを指定した場合のみです。
• スイート／テストの説明、事前条件、ステップ、期待結果、アンチパターンについては、記述ルールに厳密に従ってください。
• 規約（優先度、タグ、ラベル）については、Testomat.io TMS ガイドに従ってください。特に testomatio MCP を使用する場合は必ず従ってください。
• テストケースは と のブロックで囲んでください。
• 必要に応じて、tags: と labels: を各 `` のメタデータブロック内に記述してください（スイートのブロックだけでなく、テストのメタデータを参照してください）。
• MCP または他のテストケースから取得した既存のタグとラベルを再利用してください。
• 既存のラベルがわからない場合は、ラベルを使用しないでください。
• 妥当な場合は、分析したコンテキストに基づいてテストのメタデータ（優先度、事前条件、テストデータ、ラベル、タグ）を追加してください。
• 具体的で実行可能な値を使用してください。**初回の生成で ${...} プレースホルダーを導入しないでください。**実際に再利用される値、またはデータ駆動型の値に限りパラメーター化し、バッククォートで囲んだ ${variable} の形式にしてください。
• テストまたはスイートの ID は、いかなる種類のものも絶対に生成しないでください。
  • Testomat.io の ID（id: @T*、id: @S*、例：@T12345678、@S380c64db）を含めないでください。
  • id: フィールド、タイトル、その他の場所にカスタム ID／ランダム ID（例：TC-001、TC-R001、SUITE-01）を含めないでください。
  • Testomat.io の ID はサーバーによって生成され、ユーザーが --update-ids を指定して check-tests push を実行したとき（または sync-test-cases-with-tms スキルを通じて）に割り当てられます。生成時に ID を追加しないでください。

既存のテストケース形式との一致

ユーザーが既存のテストケースの例を提示した場合、または「類似の」テストケースを依頼した場合：

以下は合わせてください：

• 文体と詳細度
• フィールド構造（優先度、事前条件、種類、テストデータなど）
• ラベルやタグなどの追加フィールド
• 元のケースの言語

以下はコピーしないでください：

• 例に含まれるあらゆる ID（Testomat.io の ID（@T...、@S...）も、カスタム接頭辞（例：TC-R001、TC-001）も含む）
• 元のテストケースの意図

ステップ 6：概要を示す

• 簡潔な概要を示してください（Markdown の表が適しています）：テストケース数とスイート数、生成したファイル、保存先フォルダー。
• ファイルを確認し、必要であれば変更を依頼するようユーザーに伝えてください。
• sync-test-cases-with-tms スキルを使ってテストケースを Testomat.io にアップロードすることを提案してください。