QA Test Planner

QAエンジニア向けの包括的なスキルです。テスト計画の作成、手動テストケースの生成、回帰テストスイートの構築、Figmaに対するデザイン検証、バグの効果的なドキュメント化ができます。

アクティベーション: このスキルは名前で明示的に呼び出された場合のみトリガーされます（例：/qa-test-planner、qa-test-planner、または use the skill qa-test-planner）。

---

クイックスタート

テスト計画を作成：

"Create a test plan for the user authentication feature"

テストケースを生成：

"Generate manual test cases for the checkout flow"

回帰テストスイートを構築：

"Build a regression test suite for the payment module"

Figmaに対して検証：

"Compare the login page against the Figma design at [URL]"

バグレポートを作成：

"Create a bug report for the form validation issue"

---

クイックリファレンス

タスク	得られるもの	時間
テスト計画	戦略、スコープ、スケジュール、リスク	10～15分
テストケース	ステップバイステップの手順、期待結果	各5～10分
回帰スイート	スモークテスト、クリティカルパス、実行順序	15～20分
Figma検証	デザイン・実装の比較、相違点リスト	10～15分
バグレポート	再現手順、環境、証拠	5分

---

動作方法

Your Request
    │
    ▼
┌─────────────────────────────────────────────────────┐
│ 1. ANALYZE                                          │
│    • Parse feature/requirement                      │
│    • Identify test types needed                     │
│    • Determine scope and priorities                 │
├─────────────────────────────────────────────────────┤
│ 2. GENERATE                                         │
│    • Create structured deliverables                 │
│    • Apply templates and best practices             │
│    • Include edge cases and variations              │
├─────────────────────────────────────────────────────┤
│ 3. VALIDATE                                         │
│    • Check completeness                             │
│    • Verify traceability                            │
│    • Ensure actionable steps                        │
└─────────────────────────────────────────────────────┘
    │
    ▼
QA Deliverable Ready

---

コマンド

インタラクティブスクリプト

スクリプト	目的	使用方法
./scripts/generate_test_cases.sh	テストケースをインタラクティブに作成	ステップバイステップのプロンプト
./scripts/create_bug_report.sh	バグレポートを生成	ガイド付き入力収集

自然言語

リクエスト	出力
"Create test plan for {feature}"	完全なテスト計画ドキュメント
"Generate {N} test cases for {feature}"	番号付きテストケース（ステップ付き）
"Build smoke test suite"	クリティカルパステスト
"Compare with Figma at {URL}"	ビジュアル検証チェックリスト
"Document bug: {description}"	構造化されたバグレポート

---

コア成果物

1. テスト計画

• テストスコープと目的
• テストアプローチと戦略
• 環境要件
• 開始・終了条件
• リスク評価
• タイムライン・マイルストーン

2. 手動テストケース

• ステップバイステップの手順
• 期待結果と実際の結果
• 前提条件とセットアップ
• テストデータ要件
• 優先度と深刻度

3. 回帰スイート

• スモークテスト（15～30分）
• 完全回帰テスト（2～4時間）
• ターゲット回帰テスト（30～60分）
• 実行順序と依存関係

4. Figma検証

• コンポーネント別比較
• 間隔とタイポグラフィチェック
• 色とビジュアル一貫性
• インタラクティブ状態の検証

5. バグレポート

• 明確な再現手順
• 環境詳細
• 証拠（スクリーンショット、ログ）
• 深刻度と優先度

---

アンチパターン

避けるべき	理由	代わりに
曖昧なテスト手順	再現できない	具体的なアクション＋期待結果
前提条件の欠落	テストが予期なく失敗	すべてのセットアップ要件を記録
テストデータなし	テスターがブロック	サンプルデータまたは生成方法を提供
一般的なバグタイトル	追跡困難	具体的：「[機能]○○時に××が発生」
エッジケースをスキップ	重大なバグを見落とす	境界値、nullを含める

---

検証チェックリスト

テスト計画：

• スコープが明確に定義されている（対象内・対象外）
• 開始・終了条件が指定されている
• リスクと対策が識別されている
• タイムラインが現実的である

テストケース：

• 各ステップに期待結果がある
• 前提条件がドキュメント化されている
• テストデータが利用可能である
• 優先度が割り当てられている

バグレポート：

• 再現手順がある
• 環境がドキュメント化されている
• スクリーンショット/証拠が添付されている
• 深刻度/優先度が設定されている

---

参考資料

• Test Case Templates - すべてのテストタイプの標準フォーマット
• Bug Report Templates - ドキュメントテンプレート
• Regression Testing Guide - スイートの構築と実行
• Figma Validation Guide - デザイン・実装検証

---

<details> <summary><strong>詳細解説：テストケース構造</strong></summary>

標準テストケース形式

## TC-001: [テストケースのタイトル]

**優先度:** High | Medium | Low
**タイプ:** Functional | UI | Integration | Regression
**ステータス:** Not Run | Pass | Fail | Blocked

### 目的
[何をテストするのか、そしてなぜか]

### 前提条件
- [セットアップ要件 1]
- [セットアップ要件 2]
- [必要なテストデータ]

### テストステップ
1. [実行するアクション]
   **期待結果:** [起こるべきこと]

2. [実行するアクション]
   **期待結果:** [起こるべきこと]

3. [実行するアクション]
   **期待結果:** [起こるべきこと]

### テストデータ
- 入力値: [テストデータ値]
- ユーザー: [テストアカウント詳細]
- 設定: [環境設定]

### テスト後の状態
- [テスト後のシステム状態]
- [必要なクリーンアップ]

### 注記
- [検討すべきエッジケース]
- [関連テストケース]
- [既知の問題]

テストタイプ

タイプ	焦点	例
Functional	ビジネスロジック	有効な認証情報でログイン
UI/Visual	外観、レイアウト	ボタンがFigmaデザインと一致
Integration	コンポーネント間の相互作用	APIがフロントエンドにデータを返す
Regression	既存機能	以前の機能がまだ動作するか
Performance	速度、負荷処理	ページが3秒以内に読み込まれる
Security	脆弱性	SQLインジェクションが防止される

</details> <details> <summary><strong>詳細解説：テスト計画テンプレート</strong></summary>

テスト計画の構成

# テスト計画: [機能/リリース名]

## エグゼクティブサマリー
- テスト対象の機能/製品
- テスト目的
- 主なリスク
- タイムラインの概要

## テストスコープ

**対象内：**
- テスト対象の機能
- テストタイプ（機能、UI、パフォーマンス）
- プラットフォームと環境
- ユーザーフロー・シナリオ

**対象外：**
- テスト対象外の機能
- 既知の制限事項
- サードパーティ統合（該当する場合）

## テスト戦略

**テストタイプ：**
- 手動テスト
- エクスプロラトリーテスト
- 回帰テスト
- 統合テスト
- ユーザー受け入れテスト

**テストアプローチ：**
- ブラックボックステスト
- ポジティブテストとネガティブテスト
- 境界値分析
- 同値分割

## テスト環境
- オペレーティングシステム
- ブラウザとバージョン
- デバイス（モバイル、タブレット、デスクトップ）
- テストデータ要件
- バックエンド/API環境

## 開始条件
- [ ] 要件がドキュメント化されている
- [ ] デザインが確定している
- [ ] テスト環境が準備できている
- [ ] テストデータが準備できている
- [ ] ビルドがデプロイされている

## 終了条件
- [ ] すべての高優先度テストケースが実行された
- [ ] 90%以上のテストケースが合格
- [ ] すべての重大なバグが修正された
- [ ] 未解決の高深刻度バグがない
- [ ] 回帰スイートが合格

## リスク評価

| リスク | 確率 | 影響 | 対策 |
|------|------|------|------|
| [リスク 1] | H/M/L | H/M/L | [対策] |

## テスト成果物
- テスト計画ドキュメント
- テストケース
- テスト実行レポート
- バグレポート
- テスト概要レポート

</details> <details> <summary><strong>詳細解説：バグレポート</strong></summary>

バグレポートテンプレート

# BUG-[ID]: [明確で具体的なタイトル]

**深刻度:** Critical | High | Medium | Low
**優先度:** P0 | P1 | P2 | P3
**タイプ:** Functional | UI | Performance | Security
**ステータス:** Open | In Progress | Fixed | Closed

## 環境
- **OS:** [Windows 11, macOS 14, 等]
- **ブラウザ:** [Chrome 120, Firefox 121, 等]
- **デバイス:** [Desktop, iPhone 15, 等]
- **ビルド:** [バージョン/コミット]
- **URL:** [バグが発生するページ]

## 説明
[バグについての明確で簡潔な説明]

## 再現手順
1. [具体的なステップ]
2. [具体的なステップ]
3. [具体的なステップ]

## 期待される動作
[起こるべきこと]

## 実際の動作
[実際に起こったこと]

## ビジュアル証拠
- スクリーンショット: [添付]
- ビデオ: [リンク（該当する場合）]
- コンソールエラー: [エラーをペースト]

## 影響
- **ユーザーへの影響:** [影響を受けるユーザー数]
- **頻度:** [常に、時々、稀に]
- **回避策:** [存在する場合]

## 追加情報
- 関連項目: [機能/チケット]
- 回帰： [Yes/No]
- Figmaデザイン: [UIバグの場合はリンク]

深刻度の定義

レベル	基準	例
Critical (P0)	システムクラッシュ、データ損失、セキュリティ	支払い失敗、ログイン不可
High (P1)	主要機能が動作しない、回避策がない	検索が機能しない
Medium (P2)	機能が部分的に動作、回避策がある	フィルターに1つのオプションが欠落
Low (P3)	外観的な問題、稀なエッジケース	タイプ、軽微な配置ズレ

</details> <details> <summary><strong>詳細解説：Figma MCP統合</strong></summary>

デザイン検証ワークフロー

前提条件：

• Figma MCPサーバーが設定されている
• Figmaデザインファイルにアクセスできる
• Figmaコンポーネント/ページのURL

プロセス：

1. FigmaからデザインスペックをGet

"Get the button specifications from Figma file [URL]"

レスポンスに含まれるもの:
- Dimensions (width, height)
- Colors (background, text, border)
- Typography (font, size, weight)
- Spacing (padding, margin)
- Border radius
- States (default, hover, active, disabled)

2. 実装と比較

TC: Primary Button Visual Validation
1. ブラウザ開発者ツールでプライマリボタンを検査
2. Figmaスペックと比較:
   - Dimensions: 120x40px
   - Border-radius: 8px
   - Background color: #0066FF
   - Font: 16px Medium #FFFFFF
3. 相違点を記録

3. 不一致がある場合はバグを作成

BUG: Primary button color doesn't match design
Severity: Medium
Expected (Figma): #0066FF
Actual (Implementation): #0052CC
Screenshot: [attached]
Figma link: [specific component]

検証対象

要素	チェック項目	ツール
色	16進数値が正確か	ブラウザカラーピッカー
間隔	Padding/margin px	DevTools計算スタイル
タイポグラフィ	フォント、サイズ、太さ	DevToolsフォントパネル
レイアウト	幅、高さ、位置	DevToolsボックスモデル
状態	ホバー、アクティブ、フォーカス	手動操作
レスポンシブ	ブレークポイント動作	DevToolsデバイスモード

例のクエリ

"Get button specifications from Figma design [URL]"
"Compare navigation menu implementation against Figma design"
"Extract spacing values for dashboard layout from Figma"
"List all color tokens used in Figma design system"

</details> <details> <summary><strong>詳細解説：回帰テスト</strong></summary>

スイート構成

スイートタイプ	所要時間	頻度	カバレッジ
Smoke	15～30分	毎日	クリティカルパスのみ
Targeted	30～60分	変更ごと	影響を受ける領域
Full	2～4時間	週次/リリース	包括的
Sanity	10～15分	ホットフィックス後	簡易検証

回帰スイートの構築

ステップ1：クリティカルパスを特定

• ユーザーが必要とする機能は何か？
• 収益を生む機能は何か？
• 機密データを扱う機能は何か？
• 最も頻繁に使用される機能は何か？

ステップ2：テストケースの優先度付け

優先度	説明	必須実行
P0	ビジネスクリティカル、セキュリティ	常に
P1	主要機能、一般的なフロー	週次以上
P2	マイナー機能、エッジケース	リリース時

ステップ3：実行順序

1. Smoke が最初 - 失敗したら停止してビルドを修正
2. P0テストが次 - 先に進む前に合格する必要がある
3. その後P1、P2 - すべての失敗を追跡
4. エクスプロラトリー - 予期しない問題を発見

合格/不合格の基準

合格：

• すべてのP0テストが合格
• 90%以上のP1テストが合格
• 未解決の重大なバグがない

不合格（リリースブロック）：

• P0テストが失敗
• 重大なバグが発見
• セキュリティ脆弱性
• データ損失シナリオ

条件付き：

• 回避策がある場合のP1失敗
• 既知の問題がドキュメント化されている
• 修正計画がある

</details> <details> <summary><strong>詳細解説：テスト実行追跡</strong></summary>

テスト実行レポートテンプレート

# テスト実行: [リリースバージョン]

**日付:** 2024-01-15
**ビルド:** v2.5.0-rc1
**テスター:** [名前]
**環境:** Staging

## サマリー
- テストケース総数: 150
- 実行数: 145
- 合格: 130
- 失敗: 10
- ブロック: 5
- 未実行: 5
- 合格率: 90%

## テストケース（優先度別）

| 優先度 | 総数 | 合格 | 失敗 | ブロック |
|--------|------|------|------|--------|
| P0 (Critical) | 25 | 23 | 2 | 0 |
| P1 (High) | 50 | 45 | 3 | 2 |
| P2 (Medium) | 50 | 45 | 3 | 2 |
| P3 (Low) | 25 | 17 | 2 | 1 |

## 重大な失敗
- TC-045: 決済処理が失敗
  - バグ: BUG-234
  - ステータス: Open

## ブロックされたテスト
- TC-112: ダッシュボードウィジェット（APIエンドポイントダウン）

## リスク
- リリースをブロックする重大なバグが2件
- 支払い統合に注意が必要

## 次のステップ
- BUG-234修正後に再テスト
- 残り5つのテストケースを完了
- サインオフ前に完全回帰テストを実行

カバレッジ追跡

## カバレッジマトリックス

| 機能 | 要件数 | テストケース | ステータス | ギャップ |
|------|--------|------------|---------|------|
| Login | 8 | 12 | 完全 | なし |
| Checkout | 15 | 10 | 部分 | 支払いエラー |
| Dashboard | 12 | 15 | 完全 | なし |

</details> <details> <summary><strong>QAプロセスワークフロー</strong></summary>

フェーズ1：計画

• 要件とデザインをレビュー
• テスト計画を作成
• テストシナリオを特定
• 工数とタイムラインを見積もり
• テスト環境をセットアップ

フェーズ2：テスト設計

• テストケースを作成
• チームとテストケースをレビュー
• テストデータを準備
• 回帰スイートを構築
• Figmaデザインアクセスを取得

フェーズ3：実行

• テストケースを実行
• 明確なステップでバグをログ
• Figmaに対して検証（UIテスト）
• テスト進捗を追跡
• ブロッカーを通知

フェーズ4：レポート

• テスト結果をコンパイル
• カバレッジを分析
• リスクをドキュメント化
• ゴー/ノーゴーレコメンデーションを提供
• テスト成果物をアーカイブ

</details> <details> <summary><strong>ベストプラクティス</strong></summary>

テストケース作成

DO（すべきこと）：

• 具体的で曖昧性がないようにする
• 各ステップに期待結果を含める
• テストケースごとに1つのことをテスト
• 一貫した命名規則を使用
• テストケースを保守しやすく

DON'T（すべきではないこと）：

• 知識を仮定する
• テストケースを長すぎるものにする
• 前提条件をスキップ
• エッジケースを忘れる
• 期待結果を曖昧にしておく

バグレポート

DO（すべきこと）：

• 明確な再現手順を提供
• スクリーンショット/ビデオを含める
• 正確な環境詳細を指定
• ユーザーへの影響を説明
• UIバグについてはFigmaにリンク

DON'T（すべきではないこと）：

• 再現手順なしでレポート
• 曖昧な説明を使用
• 環境詳細をスキップ
• 優先度を割り当て忘れ
• 既存のバグを重複

回帰テスト

DO（すべきこと）：

• 可能な場合は反復的なテストを自動化
• 定期的に回帰スイートを保守
• クリティカルパスを優先
• 頻繁にスモークテストを実行
• 各リリース後にスイートを更新

DON'T（すべきではないこと）：

• リリース前に回帰テストをスキップ
• スイートが古くなるままにする
• 毎回すべてをテスト
• 失敗した回帰テストを無視

</details>

---

例

<details> <summary><strong>例：ログインフローテストケース</strong></summary>

## TC-LOGIN-001: 有効なユーザーログイン

**優先度:** P0 (Critical)
**タイプ:** Functional
**所要時間:** 2分

### 目的
有効な認証情報でユーザーが正常にログインできることを確認

### 前提条件
- ユーザーアカウントが存在する（test@example.com / Test123!）
- ユーザーがまだログインしていない
- ブラウザクッキーがクリアされている

### テストステップ
1. https://app.example.com/login にナビゲート
   **期待結果:** ログインページが表示される（メールとパスワード入力欄あり）

2. メールアドレスを入力: test@example.com
   **期待結果:** メール入力欄が入力を受け付ける

3. パスワードを入力: Test123!
   **期待結果:** パスワード入力欄がマスク文字を表示

4. 「Login」ボタンをクリック
   **期待結果:**
   - ローディングインジケーターが表示される
   - ユーザーが/dashboardにリダイレクトされる
   - ウェルカムメッセージが表示される：「Welcome back, Test User」
   - アバター/プロフィール画像がヘッダーに表示される

### テスト後の状態
- ユーザーセッションが作成される
- 認証トークンが保存される
- アナリティクスイベントがログされる

### 検討すべきエッジケース
- TC-LOGIN-002: 無効なパスワード
- TC-LOGIN-003: 存在しないメール
- TC-LOGIN-004: SQLインジェクション試行
- TC-LOGIN-005: 非常に長いパスワード

</details> <details> <summary><strong>例：レスポンシブデザインテストケース</strong></summary>

## TC-UI-045: モバイルナビゲーションメニュー

**優先度:** P1 (High)
**タイプ:** UI/Responsive
**デバイス:** Mobile (iPhone, Android)

### 目的
ナビゲーションメニューがモバイルデバイスで正しく動作することを確認

### 前提条件
- モバイルデバイスまたはレスポンシブモードからアクセス
- ビューポート幅: 375px (iPhone SE) ～ 428px (iPhone Pro Max)

### テストステップ
1. モバイルデバイスでホームページを開く
   **期待結果:** ハンバーガーメニューアイコンが表示される（右上）

2. ハンバーガーアイコンをタップ
   **期待結果:**
   - メニューが右からスライドイン
   - コンテンツ上にオーバーレイが表示される
   - クローズ（X）ボタンが表示される

3. メニューアイテムをタップ
   **期待結果:** セクションにナビゲート、メニューが閉じる

4. Figmaモバイルデザインと比較 [リンク]
   **期待結果:**
   - メニュー幅: 280px
   - スライドアニメーション: 300msイーズアウト
   - オーバーレイ透明度: 0.5、色 #000000
   - フォントサイズ: 16px、行間 24px

### テスト対象ブレークポイント
- 375px (iPhone SE)
- 390px (iPhone 14)
- 428px (iPhone 14 Pro Max)
- 360px (Galaxy S21)

</details>

---

「テストは、バグの存在を示しても不在を示さない。」- Edsger Dijkstra

「質の高さは行為ではなく習慣である。」- アリストテレス