回帰テストとは？かいきてすと
回帰テストとは、変更を加えた後に、変更していないはずの既存機能が壊れていないことを確かめるテスト。運用の場面では、パッチ適用・設定変更・ミドルウェアのバージョンアップといった、機能追加ではない変更のあとに実施するもので、変更管理の承認条件に「回帰テストの範囲と結果」を含めるかどうかが、変更起因のインシデントの発生率をそのまま左右する。
最終更新：2026-10-06
ITサービスマネージャを最短で暗記・合格する →背景
変更起因の障害は、変えた場所ではなく、変えていないつもりの場所で起きる。共通部品や設定値は複数の業務から使われているため、影響範囲は変更した人の頭の中にある範囲より必ず広い。この差を埋める方法は、影響範囲を宣言させたうえで、既存の試験項目を再実行して差がないことを見せることしかない。だからこそ規格でも、変更の実施後に意図した成果が得られたかをレビューすることが求められており、回帰テストはその証拠になる。
具体例
Windows Server の月例セキュリティ更新プログラムを適用したあと、検証環境で業務アプリの帳票出力・バッチ処理・外部連携までを既存の試験項目で再実行し、結果を変更記録に添付してからCABの承認を得る。Oracle Database の四半期パッチのように、実行計画が変わって特定のSQLだけ極端に遅くなる形で影響が出ることもあるため、機能の正否だけでなく主要処理の所要時間も比較対象に入れる。
試験での引っ掛け
「変更した箇所だけ試験すれば足りる」は誤りで、共通部品や設定の変更は無関係に見える機能へ波及する。運用側でありがちなのは、パッチ適用後の確認をサービスの起動確認だけで済ませることで、これは変更が動いたことの確認であって、既存機能が壊れていないことの確認にはなっていない。自動化された回帰テストがあっても、試験項目が古い仕様のままなら合格に意味はなく、項目の保守状況まで含めて有効性を判断する。
関連用語
出典・参考
解説は資格暗記が独自に作成しています。過去問の出典は各問題に記載のとおりです。