運用テストは、システムを本番で使い続けられるかを、実際の運用手順と例外時の対応で確かめる活動です。結論として、単体・結合・システム・受入テストが主に機能や要求の充足を確認するのに対し、運用テストは監視、バックアップ、権限、引継ぎ、障害復旧まで含めて運用可能性を確認します。
運用テストの定義と目的
画面が表示され、処理結果が正しくても、通知が誰にも届かない、復旧の権限を持つ人がいない、夜間障害の連絡先が古いなら、安定して使い続けることはできません。運用テストでは、定常作業だけでなく、障害、担当者不在、データ復旧、利用量の変化を想定し、手順書と体制が実際に回るかを試します。
単体・結合・システム・受入テストとの比較
| テスト | 主な確認対象 | 運用テストとの違い |
|---|---|---|
| 単体テスト | 一つの部品や処理 | 個別の処理が正しいかを見る |
| 結合テスト | 部品間の連携 | 画面・外部サービス・データ連携のつながりを見る |
| システムテスト | システム全体 | 要件どおりの機能・性能を満たすかを見る |
| 受入テスト | 利用側の受入判断 | 利用部門が業務に使えると判断できるかを見る |
| 運用テスト | 継続利用の手順と体制 | 監視、復旧、権限、引継ぎまで回るかを見る |
現場では活動が重なることがありますが、試験問題では「何を確認しているか」で選びます。プログラム単位なら単体、連携部分なら結合、全体の要求ならシステム、利用部門の受入判断なら受入、開始後の監視や復旧の手順なら運用テストです。
運用ケースで確認する試験要点
代表的な運用ケースは、毎日の開始・終了処理、利用者の追加と削除、監視アラートの受信、バックアップからの復元、障害時の一次対応、問い合わせの記録、担当者交代です。各ケースで、誰が実施するか、どの画面や権限が必要か、判断に必要な情報は何か、完了をどの記録で確認するかを試します。正常時の操作だけでは、運用テストとして十分ではありません。
仕事と日常生活での具体例
仕事で勤怠申請システムを切り替える場合、申請ボタンが動くかは機能確認の一部です。運用テストでは、締め日に処理が遅れた場合の連絡、退職者の権限削除、バックアップからの復元、承認者が休んだ場合の代理承認、監視通知を受けた担当者の初動を、実際の担当者と手順書で試します。ここで見つかった連絡先や権限の不足を直してから開始します。
日常生活では、家族で写真を共有するクラウドサービスを使い始める場面で考えられます。写真をアップロードできることに加え、機種変更後に復元できるか、共有をやめた人の閲覧権限を外せるか、容量不足の通知を誰が確認するかを試します。日々使う仕組みでは、正常操作よりも困ったときの手順が利用継続を左右します。
確認問題
問題1:障害通知を受けた担当者が、連絡網に従って復旧を依頼し、復元手順を実施できるか確認する活動はどれですか。
- A 単体テスト
- B 結合テスト
- C 受入テスト
- D 運用テスト
答え:D。監視通知、連絡、復旧という本番運用の流れを確かめているためです。
問題2:利用部門が、業務シナリオで操作して導入を受け入れられるか判断する活動はどれですか。
- A 単体テスト
- B システムテスト
- C 受入テスト
- D 運用テスト
答え:C。利用側が受入可否を判断することが中心であり、運用手順の継続性を確認する運用テストとは焦点が異なります。
次に読む記事
- 単体テスト・結合テスト・システムテストの違い:運用テストと比較する三つのテストを、V字モデルと確認対象から整理するためです。
- 結合テストとは?スタブ・ドライバとの関係:部品間の連携確認と、運用開始後を想定する確認の境目を理解するためです。
- DevOpsとは?開発と運用を連携させる考え方:テスト後も開発と運用が情報を共有して改善を続ける考え方を学ぶためです。
運用テストでは、機能が動くかだけで判断しません。誰が、異常時を含む手順を実行し、監視・復旧・引継ぎを継続できるかが焦点です。比較表と運用ケースを使い、他のテストとの違いを説明できるようにしましょう。

