リグレッションテスト
Regression。「回帰」です。一回りして戻ること（明解国語辞典）。転じて、リグレッションテストは、プログラムなどに修正を加えた時、今まで行っていた処理には何も影響が出ないことを確認するためのテストについて使われる名前です。
システム開発をやっていて大変困るのが、既存のシステムに修正を加えた時、今まで動いていたところに影響が出ないことを保証することです。新しく作った処理についてのテストは、その範囲で狙い撃ち出来るのですが、新しく作りこんだ処理が、今まで行ってきた処理の結果に何の影響も与えていないことを確認するのは大変なことです。
もし、何万、何十万もの既存のプログラム処理命令について、今回加わった修正が、悪い影響を与えていないことを確認するテストケース、テストデータを、都度作り実施することになったとしたら、その実施だけでどのくらいの人、時間、お金といったリソースが必要でしょうか。
そういうこともあり、多くの企業では、通常システム開発をする場合、単体テスト、連結テスト、統合テスト、運用テストと規模を大きくしながら検証を進めていきますが、完成して本番稼動を始めたシステムについて改定が入る場合は、こういった開発時に作成実施したテストのデータ、ツールなど、環境を保存して再利用することで、今回入った改定と既存の処理に影響がないことについての確認を行っています。
このやり方は、合理的で効果があります。しかし、改定は常に全体に手を入れるような規模で発生するとは限りません、通常は一部のサブシステムに手が入るということが、繰り返されます。修正が入った該当部分だけのリグッションが保証されても、そのシステムとデータでつながっている他システムについては保証が得られません。
とうことで、スコープを業務全体に広げ、修正の入った該当システムとつながりがあるシステムは全てリグレッションテストを実施することが必要になります。
小さな修正なのに、何でこんなにテストをしなければいけないの？ そう考える人がいても不思議ではないし、特にお金をだすユーザー発注部門の人に説明するのは大変です。しかし、既存の大規模業務システムは社会的に安全性と信頼性を要求されるものになってきています。小さな原因でも、大きな影響のあるトラブルをおこしかねません。仕事の大きさと、事故の大きさは比例しないのです（経産省『情報システムの信頼性向上に関するガイドライン』）。
大変だから、簡単な修正だから、リグレッションテストをやらなくて良いというわけにはいかないのです。
