Testing Strategy
トリガー
- •テスト計画が必要な時
- •テストスイート全体のレビュー時
- •テスト戦略の策定時
リスクベーステスト配分
| 層 | 件数 | 目的 |
|---|---|---|
| E2E | 2-5 | クリティカルパス検証 |
| Integration | 3-8 | コンポーネント連携検証 |
| Unit | 5-15 | ロジック単体検証 |
原則: E2E優先。Unit過多は設計問題のサイン。
Usefulness Score
計算: Impact(1-5) × Probability(1-5)
| スコア | 判定 | アクション |
|---|---|---|
| ≥15 | KEEP | 維持 |
| 10-14 | REVIEW | 要検討 |
| <10 | REMOVE | 削除候補 |
Impact基準
| 値 | 影響範囲 |
|---|---|
| 5 | Money/Security/Data損失 |
| 4 | 主要機能停止 |
| 3 | UX劣化 |
| 2 | 軽微な不具合 |
| 1 | 見た目のみ |
Probability基準
| 値 | 発生頻度 |
|---|---|
| 5 | 毎日発生しうる |
| 4 | 週1以上 |
| 3 | 月1以上 |
| 2 | 年1以上 |
| 1 | ほぼ発生しない |
必須カバレッジ閾値
| 領域 | 最低スコア |
|---|---|
| Money関連 | 20+ |
| Security関連 | 20+ |
| 認証/認可 | 20+ |
| データ永続化 | 15+ |
閾値未達 = リリースブロック
テスト層別実行順序
text
Database → Backend → Frontend → E2E
各層が安定してから次へ進む。
削除対象テスト
- •フレームワーク機能のテスト
- •ビジネスロジック無関係
- •重複テスト
- •Usefulness Score < 10
サブスキル
| スキル | 用途 |
|---|---|
| e2e-testing | E2Eテスト設計・実装 |
| integration-testing | 統合テスト設計・実装 |
| test-quality-audit | テスト品質監査 |
禁止事項
- •テストなしリリース
- •Usefulness未評価のテスト追加
- •フレームワークテストの作成
- •E2E 2件未満/エンドポイント