😎
3分で読めるテスト計画を“運用できる計画”に落とす具体例
この記事は『プロジェクトマネジメントの基本が全部わかる本』の学びをもとに、家計簿アプリを題材に「テスト計画」を具体化する試みです。机上の計画ではなく、現場で回せる“運用可能な計画”を目指します。以下では、画像で示される4つの手順（定義共有→用語定義→計画→マネジメント）に沿って整理します。
1. 共通認識（定義共有）
まずは「何を目的にテストするのか」をチームで一致させる。
-
目的
致命バグ（※ユーザーが利用不能になる重大な不具合）の流出防止と品質の可視化。
リリース可否（Go/No-Go）の判断材料を提供。 -
スコープ
テスト対象：入力画面、明細表示、月次集計、銀行連携、通知、課金機能。
非対象：マーケティング用ランディングページ（LP）。
2. 用語／レベル定義
共通の言葉を揃え、誤解を減らす。
-
テストレベル
- 単体テスト（UT: Unit Test）：プログラムの最小単位を検証
- 結合テスト（IT: Integration Test）：複数モジュール間の連携を確認
- E2Eテスト（End-to-End Test／シナリオテスト）：ユーザー操作を想定した一連の流れを確認
- 非機能テスト：性能・負荷・セキュリティ・回帰（※既存機能が壊れていないかの再確認）
-
入口基準／出口基準
- E2E入口：重大バグ（Severity1）がゼロであること
- E2E出口：主要ユーザーストーリーのテスト（優先度P1/P2）が100%完了、重要欠陥ゼロ
3. 計画（テスト設計の骨子）
リスク起点
- 金額計算ミス
- 重複明細の登録
- 月次集計のズレ
- 銀行API連携のタイムアウト
- 課金処理の失敗
戦略
- 高リスク機能は E2E自動化（Playwright / Cypress）
- その他は探索的テスト＋チェックリスト方式
観点表／トレーサビリティ（RTM: Requirements Traceability Matrix）
例：「予算超過通知」
- 通常ケース
- 閾値ぎりぎり
- 連続超過
- サイレント時間帯の通知制御
データ計画
- 境界値（金額0円／最大値）
- うるう年
- 日付が月を跨ぐケース
- 通貨の小数処理
- 重複キー登録
環境
- DEV（開発環境）／TEST（テスト環境）／STG（ステージング環境）
- 本番相当のAPI制限や Feature Flag（※機能のON/OFFを切り替える仕組み） を反映
性能目標
- 明細一覧：P95 < 300ms
※P95＝応答時間の95%がこの値以下である統計指標 - 月次集計：1秒以内
- 同時ログイン1,000でエラー率0.1%未満
セキュリティ
- OWASP ASVS準拠（認証、セッション管理、入力チェック、CSRF対策）
- SCA（Software Composition Analysis：依存ライブラリ脆弱性の検査）
スケジュール
- UT：2週間
- IT：1週間
- E2E＋非機能テスト：1週間
- バグ修正：1週間
役割
- QAリード：1名
- E2E自動化：2名
- 手動テスト：1名
- 開発者：自己テスト必須
ツール
4. マネジメント（運用ルール）
指標
- テスト進捗率
- 欠陥密度（コード量あたりのバグ数）
- 修正再発率
- 自動化カバレッジ（自動化済みテストの割合）
- P95遅延（応答速度指標）
レポート
- 毎日バーンダウンチャート（※残タスクの消化状況を可視化）＋重大欠陥リスト
- Severity1（致命的）：24h以内に修正
- Severity2（重要）：72h以内に修正
変更管理
- 仕様変更はRTM更新
- 影響範囲のテストケースを再実行
退出判定会議
- 指標が基準を満たすこと
- 既知リスクが承認されること
- 条件が揃えば「Go」、不十分なら「No-Go」
まとめ
「テスト計画」と聞くと分厚い文書を思い浮かべがちですが、家計簿アプリの例のように リスク起点で具体化し、運用ルールを定める ことで、実際に回せる計画へと落とし込めます。
計画が“使える”かどうかは、ツールよりも 共通認識と基準の明確さ にかかっています。
Discussion