qa-test-planner

標準のテストケース形式

## 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]

テストの種類

テスト計画の構成

# Test Plan: [Feature/Release Name]

## Executive Summary
- Feature/product being tested
- Testing objectives
- Key risks
- Timeline overview

## Test Scope

**In Scope:**
- Features to be tested
- Test types (functional, UI, performance)
- Platforms and environments
- User flows and scenarios

**Out of Scope:**
- Features not being tested
- Known limitations
- Third-party integrations (if applicable)

## Test Strategy

**Test Types:**
- Manual testing
- Exploratory testing
- Regression testing
- Integration testing
- User acceptance testing

**Test Approach:**
- Black box testing
- Positive and negative testing
- Boundary value analysis
- Equivalence partitioning

## Test Environment
- Operating systems
- Browsers and versions
- Devices (mobile, tablet, desktop)
- Test data requirements
- Backend/API environments

## Entry Criteria
- [ ] Requirements documented
- [ ] Designs finalized
- [ ] Test environment ready
- [ ] Test data prepared
- [ ] Build deployed

## Exit Criteria
- [ ] All high-priority test cases executed
- [ ] 90%+ test case pass rate
- [ ] All critical bugs fixed
- [ ] No open high-severity bugs
- [ ] Regression suite passed

## Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| [Risk 1] | H/M/L | H/M/L | [Mitigation] |

## Test Deliverables
- Test plan document
- Test cases
- Test execution reports
- Bug reports
- Test summary report

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

# 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]

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

## Additional Context
- Related to: [Feature/ticket]
- Regression: [Yes/No]
- Figma design: [Link if UI bug]

重大度の定義

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

前提条件:

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

手順:

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

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

Response includes:
- 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. 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]

検証項目

クエリの例

"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: 重要なパスを特定する

• ユーザーが絶対に手放せない機能は何か？
• 収益を生み出している機能は何か？
• 機密データを扱う機能は何か？
• 最も頻繁に使われている機能は何か？

ステップ 2: テストケースに優先順位を付ける

ステップ 3: 実行順序

1. まずスモークテスト。失敗した場合は中止し、ビルドを修正する
2. 次に P0 テスト。先に進む前に必ず合格させる
3. 次に P1、その後 P2。すべての失敗を追跡する
4. 探索的テストで、予期しない問題を見つける

合否基準

合格:

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

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

• P0 テストが 1 件でも失敗
• 重大なバグが発見された
• セキュリティ上の脆弱性
• データ損失のシナリオ

条件付き:

• 回避策のある P1 の失敗
• 既知の問題が文書化されている
• 修正計画が用意されている

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

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

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

## Blocked Tests
- TC-112: Dashboard widget (API endpoint down)

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

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

カバレッジの追跡

## Coverage Matrix

| Feature | Requirements | Test Cases | Status | Gaps |
|---------|--------------|------------|--------|------|
| Login | 8 | 12 | Complete | None |
| Checkout | 15 | 10 | Partial | Payment errors |
| Dashboard | 12 | 15 | Complete | None |

フェーズ 1: 計画

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

フェーズ 2: テスト設計

• テストケースを作成する
• テストケースをチームでレビューする
• テストデータを準備する
• リグレッションスイートを構築する
• Figma デザインへのアクセス権を取得する

フェーズ 3: 実行

• テストケースを実行する
• 明確な手順でバグを記録する
• Figma と照合して検証する（UI テスト）
• テストの進捗を追跡する
• ブロッカーを共有する

フェーズ 4: レポート作成

• テスト結果をまとめる
• カバレッジを分析する
• リスクを文書化する
• Go/No-Go の推奨を提示する
• テスト成果物をアーカイブする

テストケースの作成

DO:

• 具体的で曖昧さのない記述にする
• 各ステップに期待される結果を含める
• 1 つのテストケースでは 1 つのことだけをテストする
• 一貫した命名規則を使用する
• 保守しやすいテストケースにする

DON'T:

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

バグレポート

DO:

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

DON'T:

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

リグレッションテスト

DO:

• 可能な場合は反復的なテストを自動化する
• リグレッションスイートを定期的にメンテナンスする
• 重要なパスを優先する
• スモークテストを頻繁に実行する
• リリースごとにスイートを更新する

DON'T:

• リリース前のリグレッションを省略しない
• スイートを古いままにしない
• 毎回すべてをテストしない
• 失敗したリグレッションテストを無視しない

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

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

## 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)