ソフトウェアリグレッション（英語: software regression）は、システムのアップグレード、システムの更新プログラム適用、夏時間への変更などの特定のイベントの後で、機能が意図したとおりに機能しなくなるソフトウェアのバグのこと[1]。 ソフトウェアの後退・後戻り・先祖返り、またはデグレード（degrade、デグレ）とも呼ばれる。ソフトウェアパフォーマンスのリグレッションは、ソフトウェアが正常に機能しているにもかかわらず、パフォーマンスが遅くなったり、以前よりも多くのメモリやリソースを使用したりする状況のこと[2]。

リグレッションは、多くの場合、ソフトウェア更新プログラムに含まれているバグ修正によって引き起こされる。この種の問題を回避するためには、回帰テストを行うことが一つのアプローチとなる。適切に設計されたテスト計画（英語版）は、ソフトウェアをリリースする前にリグレッションの可能性を防ぐことを目的としている[3]。 自動化されたテストと適切に記述されたテストケースにより、リグレッションの可能性を減らすことができる。

ソフトウェアのリグレッションは、次の3つのタイプのいずれかになる。

ローカル ? 変更により、変更されたモジュールやコンポーネントに新しいバグが発生する。

リモート ? ソフトウェアの一部を変更することで、別のモジュールやコンポーネントの機能が損なわれる。

露呈 ? 変更により、変更前には影響がなかった既存のバグが露呈する。

予防と検出

これまでに、さまざまな開発段階でのリグレッションの導入を防止する技術が提案されてきた。以下に概略を説明する。
リリース前

リグレッションがエンドユーザーに現れるのを避ける目的で、ソフトウェアに変更が加えられた後、開発者はリグレッションテストを定期的に実行する。こうしたテストには、ローカルのリグレッションを発見するための単体テストと、リモートのリグレッションを発見するための統合テストがある[4]。回帰テストの技法では、既存のテストケースを活用して、テストケースの作成に伴う労力を最小限に抑えることがよくある[5]。しかし、こうした既存のテストは量が多いため、多くの場合、テストケースの優先付けなどの技法を使用して代表的なサブセットを選択する必要がある。

性能のリグレッションを検出するために、後続の変更後のレスポンスタイムとリソース使用量のメトリクスを計測するソフトウェアパフォーマンステストが定期的に実行される[6]。機能の回帰テストとは異なり、パフォーマンステストの結果は分散する可能性がある。つまり、パフォーマンス測定値のばらつきにより、結果はテスト間で異なる場合がある。そのため、パフォーマンス数値の変化がリグレッションを構成するかどうかは、経験とエンドユーザーからの要求に基づいて決定する必要がある。この決定を支援するために、統計的有意性検定や変化点検出（英語版）などのアプローチが使用されることもある[7]。
コミット前

ソフトウェアのリグレッションでは、デバッグや根本的な原因の特定には高いコストがかかるため[8][9]、そもそもリグレッション自体がコードリポジトリにコミットされるのを防止する手法も存在する。たとえば、Git Hooksを利用すると、コードの変更をコミットまたはプッシュするときに自動的にテストスクリプトを実行できる[10]。また、コード変更がプログラムのさまざまなコンポーネントに与える影響を予測し、テストケースの選択と優先順位付けを補助とするために、変更の影響分析（英語版）も行われている[11][12]。コミットhookにはソフトウェアlinterもよく追加される[13]。linterにより、一貫したコードスタイルを保証することができ、リグレッションが起こりやすくなるスタイルの問題を最小化することができる[13]。