QAテストケース生成スキル

品質保証のための包括的で構造化されたテストケースを生成します。

使用方法

テストケースを生成する際は、以下の手順に従ってください:

1. 機能の分析

• ユーザーストーリーや要件を読んで理解する
• ユーザーの操作フロー、画面遷移、エッジケースを特定する
• 機能要件とユーザビリティ要件の両方を考慮する

2. テストケースの構造

各テストケースには以下を含めます:

• テストケースID: 一意の識別子（例: TC001, TC002）
• テスト名: 明確で説明的な名前
• テスト目的: このテストで何を検証するか
• 前提条件: テスト実行前に必要なセットアップ
• テスト手順: 番号付きの明確な実行ステップ
• 期待結果: 各ステップで期待される結果
• 優先度: Critical（必須）、High（高）、Medium（中）、Low（低）
• テストタイプ: 機能テスト、統合テスト、回帰テスト、境界値テストなど

3. カバーすべき領域

• ハッピーパス（正常な操作フロー）
• エッジケース（境界条件、特殊な入力）
• エラーハンドリング（異常な操作、誤入力）
• 画面遷移とナビゲーション
• データの表示・検証
• ユーザビリティとアクセシビリティ
• 複数デバイス・ブラウザでの動作

4. 出力フォーマット

テストケースは以下のように構造化されたMarkdown形式で提供します:

• テスト管理ツールへのコピーが容易
• ドキュメントとして使用可能
• QAチームと共有しやすい

使用例

入力

「メールアドレスとパスワードを受け付けるログイン機能のテストケースを作成してください」

出力例

## ログイン機能のテストケース

### TC001: 有効な認証情報でのログイン成功
- **テスト目的**: 正しいメールアドレスとパスワードでログインできることを確認
- **前提条件**: システムにユーザーアカウントが存在する
- **テスト手順**:
  1. ログインページに移動する
  2. 有効なメールアドレスを入力する
  3. 有効なパスワードを入力する
  4. 「ログイン」ボタンをクリックする
- **期待結果**:
  - ユーザーが認証される
  - ダッシュボードにリダイレクトされる
  - セッションが作成される
- **優先度**: Critical
- **テストタイプ**: 機能テスト

### TC002: 無効なメール形式でのログイン失敗
- **テスト目的**: システムが無効なメール形式を拒否することを確認
- **前提条件**: なし
- **テスト手順**:
  1. ログインページに移動する
  2. 無効なメールアドレスを入力する（例: "notanemail"）
  3. 有効なパスワードを入力する
  4. 「ログイン」ボタンをクリックする
- **期待結果**:
  - エラーメッセージ: 「メールアドレスの形式が正しくありません」
  - ログインページに留まる
  - セッションは作成されない
- **優先度**: High
- **テストタイプ**: 機能テスト、バリデーション

### TC003: 誤ったパスワードでのログイン失敗
- **テスト目的**: システムが誤ったパスワードを拒否することを確認
- **前提条件**: 有効なユーザーアカウントが存在する
- **テスト手順**:
  1. ログインページに移動する
  2. 有効なメールアドレスを入力する
  3. 誤ったパスワードを入力する
  4. 「ログイン」ボタンをクリックする
- **期待結果**:
  - エラーメッセージ: 「認証情報が正しくありません」
  - ログインページに留まる
  - ログイン失敗がログに記録される
- **優先度**: Critical
- **テストタイプ**: 機能テスト、セキュリティ

追加の考慮事項

• テストデータ: 具体的なテストデータ例を含める（例: 「山田太郎」「test@example.com」）
• アクセシビリティ: キーボードのみでの操作、フォントサイズ変更時の表示確認
• ユーザーロール: 管理者、一般ユーザーなど、複数の権限での動作確認
• 画面遷移: 戻るボタン、ブラウザバック、タブ切り替えでの動作
• エラーメッセージ: ユーザーが理解できる日本語で表示されているか
• 入力制限: 全角/半角、文字数制限、禁止文字の動作確認

ベストプラクティス

• テストケースは独立しており、任意の順序で実行可能にする
• 各テストケースは単一の明確な目的を持つ
• 常にユーザー視点を考慮する
• ポジティブケース（正常系）とネガティブケース（異常系）の両方を含める
• テストケース作成時の前提条件や仮定を文書化する
• 実際のユーザーシナリオに基づいてテストケースを作成する
• 定期的にテストケースをレビューし、更新する