回帰テスト
一部のプロジェクトでは、自動システムをセットアップして、指定された間隔ですべての回帰テストを再実行し、障害を報告する(これは回帰または古いテストを意味する可能性がある)。 一般的な戦略では、コンパイルが成功するたびに(小さなプロジェクトの場合)、毎晩、または週に1回、このようなシステムを実行する。これらの戦略は、外部ツールによって自動化できる。
回帰テストは、エクストリームプログラミングソフトウェア開発手法の不可欠な部分である。この方法では、設計ドキュメントは、ソフトウェア開発プロセスの各段階を通じて、ソフトウェアパッケージ全体の広範囲にわたる反復可能な自動テストに置き換えられる。回帰テストは、機能テストが終了した後に実行され、他の機能が機能していることを確認する。
企業の世界では、従来、回帰テストは、開発チームが作業を完了した後にソフトウェア品質保証チームによって実行されてきた。ただし、この段階で見つかった欠陥は、修正するのに最も費用がかかる。この問題は、単体テストによって対処されている。開発者は常に、開発サイクルの一環として、テストケースを書いているが、これらのテストケースは、一般的にどちらかだった機能テストや単体テストのみ意図成果を検証する。開発者テストでは、開発者は単体テストに集中し、ポジティブテストケースとネガティブテストケースの両方を含める必要がある。
回帰テスト (かいきテスト、英: regression testing) とは、前にテストしたソフトウェアが変更後もまだ動作するかどうかを、機能テストと非機能テストを再度実行して確認する作業のこと。退行テスト、リグレッションテストとも呼ばれる。そうでない場合、それは先祖返りと呼ばれる。回帰テストが必要になる可能性のある変更には、バグ修正、ソフトウェアの機能強化、構成変更、さらには電子部品の置き換えなどある。 リグレッションをテストするための仕組みは、欠陥が見つかるたびに大きくなる傾向があるため、通常はテストの自動化でカバーされる。テストするためのテストケースを決定するために、変更影響分析を実行することもある(非回帰分析 )。