qa-test-planner

QA テスト計画

QA エンジニアがテスト計画を作成し、手動テストケースを生成し、回帰テストスイートを構築し、Figma に照らしてデザインを検証し、効果的にバグを記録するための包括的なスキルです。

このスキルでできること

QA エンジニアを次のように支援します。

• テスト計画の作成 - 包括的なテスト戦略と計画の策定
• 手動テストケースの生成 - 詳細なステップごとのテストケースの作成
• 回帰テストスイート - クリティカルパスおよびスモークテストスイートの作成
• Figma デザインの検証 - 実装とデザインの比較（Figma MCP が必要です）
• バグ報告テンプレート - 明確で再現可能なバグの記録
• テストカバレッジ分析 - テストの不足箇所を特定
• テスト実行の追跡 - テストの進捗を監視

このスキルが必要な理由

体系的なテストがない場合：

• テストカバレッジに一貫性がない
• エッジケースを見落とす
• バグの記録が不十分
• 回帰テストによる安全網がない
• デザインの実装漏れ
• テスト戦略が不明確

このスキルを使うと：

• 包括的なテストカバレッジ
• 繰り返し実行できるテストケース
• 体系的な回帰テスト
• デザインと実装の検証
• プロフェッショナルなバグ報告
• 明確なテストロードマップ

主な構成要素

1. テスト計画ジェネレーター

• テスト範囲と目標
• テストのアプローチと戦略
• テスト環境の要件
• 開始／終了基準
• リスク評価
• リソースの割り当て
• スケジュールとマイルストーン

2. 手動テストケースジェネレーター

• ステップごとの手順
• 期待される結果と実際の結果
• 前提条件とセットアップ
• テストデータの要件
• 優先度と重大度
• エッジケースの特定

3. 回帰テストスイートビルダー

• スモークテストケース
• クリティカルパステスト
• 統合テストのシナリオ
• 後方互換性のチェック
• パフォーマンス回帰テスト

4. Figma デザインの検証（MCP を使用）

• UI の実装とデザインを比較
• 視覚的な差異を特定
• 余白、色、タイポグラフィを検証
• コンポーネントの一貫性を確認
• デザインと開発の不一致を指摘

5. バグレポートジェネレーター

• 明確な再現手順
• 環境の詳細
• 期待される動作と実際の動作
• スクリーンショットと証拠
• 重大度と優先度
• 関連するテストケース

テストケースの構成

標準的なテストケース形式

## TC-001: [Test Case Title]

**Priority:** High | Medium | Low
**Type:** Functional | UI | Integration | Regression
**Status:** Not Run | Pass | Fail | Blocked

### Objective
[What are we testing and why]

### Preconditions
- [Setup requirement 1]
- [Setup requirement 2]
- [Test data needed]

### Test Steps
1. [Action to perform]
   **Expected:** [What should happen]

2. [Action to perform]
   **Expected:** [What should happen]

3. [Action to perform]
   **Expected:** [What should happen]

### Test Data
- Input: [Test data values]
- User: [Test account details]
- Configuration: [Environment settings]

### Post-conditions
- [System state after test]
- [Cleanup required]

### Notes
- [Edge cases to consider]
- [Related test cases]
- [Known issues]

テスト計画テンプレート

エグゼクティブサマリー

• テスト対象の機能／製品
• テストの目標
• 主なリスク
• スケジュールの概要

テスト範囲

対象範囲：

• テスト対象の機能
• テストの種類（機能、UI、パフォーマンスなど）
• プラットフォームと環境
• ユーザーフローとシナリオ

対象外：

• テスト対象外の機能（延期）
• 既知の制限事項
• サードパーティとの連携（該当する場合）

テスト戦略

テストの種類：

• 手動テスト
• 探索的テスト
• 回帰テスト
• 統合テスト
• ユーザー受け入れテスト
• パフォーマンステスト（該当する場合）

テストのアプローチ：

• ブラックボックステスト
• ポジティブテストとネガティブテスト
• 境界値分析
• 同値分割

テスト環境

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

開始基準

• 要件が文書化されている
• デザインが確定している
• テスト環境の準備ができている
• テストデータが用意されている
• ビルドがテスト環境にデプロイされている

終了基準

• 優先度の高いテストケースをすべて実行済み
• テストケースの合格率が 90% 以上
• 重大なバグをすべて修正済み
• 重大度の高い未解決バグがない
• 回帰テストスイートに合格している
• ステークホルダーの承認を得ている

リスク評価

リスク	発生確率	影響度	軽減策
[Risk 1]	High/Med/Low	High/Med/Low	[How to mitigate]
[Risk 2]	High/Med/Low	High/Med/Low	[How to mitigate]

テスト成果物

• テスト計画書
• テストケース
• テスト実行レポート
• バグレポート
• テストサマリーレポート

テストの種類とアプローチ

1. 機能テスト

内容： 仕様どおりに機能することを確認します

テストケース：

• 正常系のシナリオ
• エラー処理
• 入力値の検証
• ビジネスロジック
• データの整合性

例：

TC: User Login with Valid Credentials
1. Navigate to login page
2. Enter valid email and password
3. Click "Login" button
Expected: User redirected to dashboard, welcome message shown

2. UI／ビジュアルテスト

内容： ビジュアルの外観とレイアウトを確認します

テストケース：

• レイアウトと配置
• レスポンシブデザイン
• 色とタイポグラフィ
• コンポーネントの状態（ホバー、アクティブ、無効）
• クロスブラウザー互換性

Figma MCP を使用する場合：

• 実装を Figma のデザインと比較する
• 間隔（パディング、マージン）を確認する
• フォントサイズとウェイトを確認する
• 色の値を検証する
• アイコンが正確であることを確認する

例：

TC: Homepage Hero Section Visual Validation
1. Open homepage in browser
2. Compare against Figma design [link]
3. Verify:
   - Heading font: 48px, bold, #1A1A1A
   - CTA button: 16px padding, #0066FF background
   - Image aspect ratio: 16:9
   - Spacing: 64px margin-bottom
Expected: All visual elements match Figma exactly

3. 回帰テスト

内容： 既存の機能が引き続き動作することを確認します

実行タイミング：

• リリース前
• バグ修正後
• 新機能の追加後
• 毎週のスモークテスト

テストスイートの構成要素：

• スモークテスト（重要な経路）
• 全回帰テスト（包括的なテスト）
• 対象を絞った回帰テスト（影響を受ける領域）

例：

Regression Suite: User Authentication
- Login with valid credentials
- Login with invalid credentials
- Password reset flow
- Session timeout handling
- Multi-device login
- Social login (Google, GitHub)

4. 統合テスト

内容： さまざまなコンポーネントが連携して動作することを確認します

テストケース：

• API 統合
• データベース操作
• サードパーティサービス
• モジュール間の連携
• コンポーネント間のデータフロー

例：

TC: Checkout Payment Integration
1. Add item to cart
2. Proceed to checkout
3. Enter payment details (Stripe)
4. Submit payment
Expected:
- Payment processed via Stripe API
- Order created in database
- Confirmation email sent
- Inventory updated

5. 探索的テスト

内容： スクリプトに沿わず、創造的に行うテストです

アプローチ：

• チャーターに基づく探索
• ユーザーペルソナのシミュレーション
• エッジケースの発見
• ユーザビリティの評価

セッションテンプレート：

Exploratory Testing Session
Charter: Explore [feature] as [user type]
Time: 60 minutes
Focus: [Area to explore]

Findings:
- [Bug/issue discovered]
- [UX concern]
- [Improvement suggestion]

Follow-up:
- [Test cases to create]
- [Bugs to file]

Figma MCP の統合

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

前提条件：

• Figma MCP サーバーが設定済みであること
• デザインファイルにアクセスできること
• Figma URL を利用できること

検証プロセス：

1. Figma からデザイン仕様を取得する

"Get the button specifications from Figma file [URL]"
- Component: Primary Button
- Width: 120px
- Height: 40px
- Border-radius: 8px
- Background: #0066FF
- Font: 16px, Medium, #FFFFFF

2. 実装と比較する

TC: Primary Button Visual Validation
1. Inspect primary button in browser dev tools
2. Compare against Figma specs:
   - Dimensions: 120x40px ✓ / ✗
   - Border-radius: 8px ✓ / ✗
   - Background color: #0066FF ✓ / ✗
   - Font: 16px Medium #FFFFFF ✓ / ✗
3. Document discrepancies

3. 不一致があればバグを起票する

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

デザインと開発の引き継ぎチェックリスト

Figma MCP を使用する場合：

• デザインから間隔の値を取得する
• カラーパレットが一致することを確認する
• タイポグラフィの仕様を確認する
• コンポーネントの状態（ホバー、アクティブ、無効）を検証する
• ブレークポイントの動作を確認する
• アイコンとアセットを確認する
• アクセシビリティに関する注釈を確認する

バグ報告のベストプラクティス

効果的なバグ報告テンプレート

# BUG-[ID]: [Clear, specific title]

**Severity:** Critical | High | Medium | Low
**Priority:** P0 | P1 | P2 | P3
**Type:** Functional | UI | Performance | Security
**Status:** Open | In Progress | Fixed | Closed

## Environment
- **OS:** [Windows 11, macOS 14, etc.]
- **Browser:** [Chrome 120, Firefox 121, etc.]
- **Device:** [Desktop, iPhone 15, etc.]
- **Build:** [Version/commit]
- **URL:** [Page where bug occurs]

## Description
[Clear, concise description of the issue]

## Steps to Reproduce
1. [Specific step]
2. [Specific step]
3. [Specific step]

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

## Visual Evidence
- Screenshot: [attached]
- Video: [link if applicable]
- Console errors: [paste errors]
- Network logs: [if relevant]

## Impact
- **User Impact:** [How many users affected]
- **Frequency:** [Always, Sometimes, Rarely]
- **Workaround:** [If one exists]

## Additional Context
- Related to: [Feature/ticket]
- First noticed: [When]
- Regression: [Yes/No - if yes, since when]
- Figma design: [Link if UI bug]

## Test Cases Affected
- TC-001: [Test case that failed]
- TC-045: [Related test case]

バグの重大度の定義

クリティカル（P0）：

• システムのクラッシュまたはデータの損失
• セキュリティ上の脆弱性
• 機能が完全に使用不能
• リリースを妨げる

高（P1）：

• 主要な機能が動作しない
• ユーザーへの影響が大きい
• 回避策がない
• リリース前に修正すべき

中（P2）：

• 機能が部分的に動作する
• 回避策がある
• ユーザーに軽微な不便が生じる
• 次回のリリースで修正する前提で出荷できる

低（P3）：

• 外観上の問題
• まれなエッジケース
• 影響が最小限
• 修正できれば望ましい

テストカバレッジの分析

カバレッジ指標

機能カバレッジ：

Total Features: 25
Tested: 23
Not Tested: 2
Coverage: 92%

要件カバレッジ：

Total Requirements: 150
With Test Cases: 142
Without Test Cases: 8
Coverage: 95%

リスクカバレッジ：

High-Risk Areas: 12
Tested: 12
Medium-Risk: 35
Tested: 30

カバレッジマトリックス

機能	要件	テストケース	状態	不足項目
ログイン	8	12	✓ 完了	なし
チェックアウト	15	10	⚠ 一部完了	決済エラー
ダッシュボード	12	15	✓ 完了	なし

回帰テストスイートの構成

スモークテストスイート（15～30 分）

実行： 各テストサイクルの前、日次ビルド時

重要な経路：

• ユーザーのログイン／ログアウト
• コアとなるユーザーフロー（例：注文の作成）
• ナビゲーションとルーティング
• API のヘルスチェック
• データベースへの接続

例：

SMOKE-001: Critical User Flow
1. Login as standard user
2. Navigate to main feature
3. Perform primary action
4. Verify success message
5. Logout
Expected: All steps complete without errors

全回帰テストスイート（2～4 時間）

実行： 毎週、リリース前

カバレッジ：

• すべての機能テストケース
• 統合シナリオ
• UI の検証
• クロスブラウザーチェック
• データ整合性テスト

対象を絞った回帰テスト（30～60 分）

実行： バグ修正後、機能の更新後

カバレッジ：

• 影響を受ける機能領域
• 関連コンポーネント
• 統合ポイント
• 以前に失敗したテスト

テスト実行の追跡

テスト実行テンプレート

# Test Run: [Release Version]

**Date:** 2024-01-15
**Build:** v2.5.0-rc1
**Tester:** [Name]
**Environment:** Staging

## Summary
- Total Test Cases: 150
- Executed: 145
- Passed: 130
- Failed: 10
- Blocked: 5
- Not Run: 5
- Pass Rate: 90%

## Test Cases by Priority

| Priority | Total | Pass | Fail | Blocked |
|----------|-------|------|------|---------|
| P0 (Critical) | 25 | 23 | 2 | 0 |
| P1 (High) | 50 | 45 | 3 | 2 |
| P2 (Medium) | 50 | 45 | 3 | 2 |
| P3 (Low) | 25 | 17 | 2 | 1 |

## Failures

### Critical Failures
- TC-045: Payment processing fails
  - Bug: BUG-234
  - Status: Open

### High Priority Failures
- TC-089: Email notification not sent
  - Bug: BUG-235
  - Status: In Progress

## Blocked Tests
- TC-112: Dashboard widget (API endpoint down)
- TC-113: Export feature (dependency not deployed)

## Risks
- 2 critical bugs blocking release
- Payment integration needs attention
- Email service intermittent

## Next Steps
- Retest after BUG-234 fix
- Complete remaining 5 test cases
- Run full regression before sign-off

このスキルの使用方法

テスト計画を作成する

./scripts/generate_test_plan.sh

包括的なテスト計画を作成するための対話型ワークフロー。

手動テストケースを作成する

./scripts/generate_test_cases.sh

機能の手動テストケースを、手順ごとの説明付きで作成します。

回帰テストスイートを構築する

./scripts/build_regression_suite.sh

スモークテストスイートと回帰テストスイートを作成します。

Figma でデザインを検証する

Figma MCP が設定されている場合：

"Compare the login page implementation against the Figma design at [URL] and generate test cases for visual validation"

バグレポートを作成する

./scripts/create_bug_report.sh

必要な詳細情報をすべて含む、構造化されたバグレポートを生成します。

テンプレートにアクセスする

references/test_case_templates.md - Various test case formats
references/bug_report_templates.md - Bug documentation templates
references/regression_testing.md - Regression testing guide
references/figma_validation.md - Design validation with Figma MCP

QA プロセスのワークフロー

1. 計画フェーズ

• 要件とデザインを確認する
• テスト計画を作成する
• テストシナリオを特定する
• 工数とスケジュールを見積もる
• テスト環境をセットアップする

2. テスト設計フェーズ

• テストケースを作成する
• チームでテストケースをレビューする
• テストデータを準備する
• 回帰テストスイートを構築する
• Figma のデザインにアクセスできるようにする

3. テスト実行フェーズ

• テストケースを実行する
• 明確な再現手順とともにバグを記録する
• Figma のデザインと照合して検証する（UI テスト）
• テストの進捗を追跡する
• 作業を妨げる問題を共有する

4. レポートフェーズ

• テスト結果をまとめる
• カバレッジを分析する
• リスクを文書化する
• リリース可否を提案する
• テスト成果物をアーカイブする

ベストプラクティス

テストケースの作成

推奨事項：

• ✅ 具体的で曖昧さのない記述にする
• ✅ 各ステップの期待結果を記載する
• ✅ 1 つのテストケースで 1 つの項目をテストする
• ✅ 一貫した命名規則を使用する
• ✅ テストケースを保守しやすくする

非推奨事項：

• ❌ 知識があることを前提にしない
• ❌ テストケースを長くしすぎない
• ❌ 前提条件を省略しない
• ❌ エッジケースを忘れない
• ❌ 期待結果を曖昧なままにしない

バグの報告

推奨事項：

• ✅ 明確な再現手順を示す
• ✅ スクリーンショットや動画を含める
• ✅ 環境の詳細を正確に記載する
• ✅ ユーザーへの影響を説明する
• ✅ UI のバグには Figma へのリンクを付ける

非推奨事項：

• ❌ 再現手順なしで報告しない
• ❌ 曖昧な説明を使わない
• ❌ 環境の詳細を省略しない
• ❌ 優先度の割り当てを忘れない
• ❌ 既存のバグを重複して報告しない

回帰テスト

推奨事項：

• ✅ 可能であれば、反復的なテストを自動化する
• ✅ 回帰テストスイートを定期的に保守する
• ✅ 重要な経路を優先する
• ✅ スモークテストを頻繁に実行する
• ✅ リリースごとにスイートを更新する

非推奨事項：

• ❌ リリース前の回帰テストを省略しない
• ❌ スイートを古いままにしない
• ❌ 毎回すべてをテストしない
• ❌ 失敗した回帰テストを無視しない

Figma MCP のセットアップ

設定

Figma MCP サーバーをインストールする：

# Follow Figma MCP installation instructions
# Configure with your Figma API token
# Set file access permissions

テスト計画での使用方法：

"Analyze the Figma design file at [URL] and generate visual validation test cases for:
- Color scheme compliance
- Typography specifications
- Component spacing
- Responsive breakpoints
- Interactive states"

クエリの例：

"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"

テストケースの例

例 1：ログインフロー

## TC-LOGIN-001: Valid User Login

**Priority:** P0 (Critical)
**Type:** Functional
**Estimated Time:** 2 minutes

### Objective
Verify users can successfully login with valid credentials

### Preconditions
- User account exists ([email protected] / Test123!)
- User is not already logged in
- Browser cookies cleared

### Test Steps
1. Navigate to https://app.example.com/login
   **Expected:** Login page displays with email and password fields

2. Enter email: [email protected]
   **Expected:** Email field accepts input

3. Enter password: Test123!
   **Expected:** Password field shows masked characters

4. Click "Login" button
   **Expected:**
   - Loading indicator appears
   - User redirected to /dashboard
   - Welcome message shown: "Welcome back, Test User"
   - Avatar/profile image displayed in header

### Post-conditions
- User session created
- Auth token stored
- Analytics event logged

### Visual Validation (with Figma)
- Compare dashboard layout against Figma design [link]
- Verify welcome message typography: 24px, Medium, #1A1A1A
- Check avatar size: 40x40px, border-radius 50%

### Edge Cases to Consider
- TC-LOGIN-002: Invalid password
- TC-LOGIN-003: Non-existent email
- TC-LOGIN-004: SQL injection attempt
- TC-LOGIN-005: Very long password

例 2：レスポンシブデザインの検証

## TC-UI-045: Mobile Navigation Menu

**Priority:** P1 (High)
**Type:** UI/Responsive
**Devices:** Mobile (iPhone, Android)

### Objective
Verify navigation menu works correctly on mobile devices

### Preconditions
- Access from mobile device or responsive mode
- Viewport width: 375px (iPhone SE) to 428px (iPhone Pro Max)

### Test Steps
1. Open homepage on mobile device
   **Expected:** Hamburger menu icon visible (top-right)

2. Tap hamburger icon
   **Expected:**
   - Menu slides in from right
   - Overlay appears over content
   - Close (X) button visible

3. Tap menu item
   **Expected:** Navigate to section, menu closes

4. Compare against Figma mobile design [link]
   **Expected:**
   - Menu width: 280px
   - Slide animation: 300ms ease-out
   - Overlay opacity: 0.5, color #000000
   - Font size: 16px, line-height 24px

### Breakpoints to Test
- 375px (iPhone SE)
- 390px (iPhone 14)
- 428px (iPhone 14 Pro Max)
- 360px (Galaxy S21)

まとめ

この QA テストプランナーのスキルでは、次のことができます。

• 体系的なテスト計画 - 包括的なテスト戦略
• 手動テストケースの生成 - 詳細で再現可能なテスト
• 回帰テスト - 変更による不具合を防止
• Figma による検証 - デザインと実装の照合
• バグの文書化 - 明確で実行可能なレポート
• カバレッジ分析 - テストの不足箇所を特定

忘れないでください： 品質は全員の責任ですが、QA は品質が体系的に検証されるようにします。

---

「テストはバグの存在を示すものであり、不在を示すものではない。」- Edsger Dijkstra

「品質とは行為ではなく、習慣である。」- Aristotle