回帰テスト背景.ソフトウェアが更新または変更されたり、変更されたターゲットで再利用されたりすると、新しい障害の発生や古い障害の再発生が非常に一般的である。不十分なリビジョン管理手法(またはリビジョン管理における単純な人為的エラー)によって修正が失われるために、再出現が発生することがある。多くの場合、問題の修正は「脆弱」であり、最初に観察された狭いケースでは問題が修正されるが、ソフトウェアの存続期間中に発生する可能性のあるより一般的なケースでは修正されない。多くの場合、ある領域の問題を修正すると、別の領域でソフトウェアのバグが発生する。最後に、一部の機能が再設計されると、その機能の元の実装で行われたのと同じ間違いのいくつかが再設計で行われる場合がある。回帰テストは、エクストリームプログラミングソフトウェア開発手法の不可欠な部分である。この方法では、設計ドキュメントは、ソフトウェア開発プロセスの各段階を通じて、ソフトウェアパッケージ全体の広範囲にわたる反復可能な自動テストに置き換えられる。回帰テストは、機能テストが終了した後に実行され、他の機能が機能していることを確認する。企業の世界では、従来、回帰テストは、開発チームが作業を完了した後にソフトウェア品質保証チームによって実行されてきた。ただし、この段階で見つかった欠陥は、修正するのに最も費用がかかる。この問題は、単体テストによって対処されている。開発者は常に、開発サイクルの一環として、テストケースを書いているが、これらのテストケースは、一般的にどちらかだった機能テストや単体テストのみ意図成果を検証する。開発者テストでは、開発者は単体テストに集中し、ポジティブテストケースとネガティブテストケースの両方を含める必要がある。テクニック.回帰テスト手法は次のとおり。すべてを再テスト.現在のプログラムのすべてのテストケースをチェックして、その整合性をチェックする。すべてのケースを再実行する必要があるためコストがかかるが、コードが変更されたためにエラーが発生しないことが保証される。回帰テストの選択.すべてを再テストするのとは異なり、この手法は、テストスイートの一部を選択するコストがすべてを再テストする手法よりも少ない場合、テストスイートの一部を実行する(すべてを再テストするコストがかかるため)。