回帰テスト（リグレッションテスト）

回帰テストは、変更によって以前は動いていたものが壊れていないかを確認するテストです。「リグレッション（回帰・退行）」とは、以前のビルドでは動いていたのに、今は動かなくなった機能のことです。バグ修正、新機能の追加、リファクタリング、依存関係のアップグレード、設定変更のたびに、既存の振る舞いに対するテストを再実行することでこれを検出します。

例

あるチームが決済画面に「ギフトカードで支払う」オプションを追加します。新機能には専用のテストが作られます。回帰テストが問うのは別のことです。カード決済、割引コード、税計算、注文確認メールは、以前とまったく同じように動作するでしょうか？価格計算モジュールへの共通の変更は、新しいコードパスに触れなくても、これらのどれでも簡単に壊してしまう可能性があります。

実行するテストの選び方

コミットのたびにすべてのテストを実行するのが最もシンプルな戦略で、高速な自動テストスイートがあれば、多くの場合それが正解です。フルスイートが遅すぎる、あるいは一部が手動の場合、チームは次の基準で選びます。

• リスク別。 ビジネス上重要なフロー（会員登録、決済、データのエクスポート）は常に実行します。
• 影響範囲別。 変更とコード、データ、サービスを共有している領域です。
• 履歴別。 過去にリグレッションが起きたモジュールは、また起きやすい傾向があります。

よくある分け方は、プルリクエストごとに高速な回帰テストのサブセットを実行し、フルスイートは夜間またはリリース前に実行するというものです。

チームが最初に自動化する理由

回帰テストは、同じ手順を同じ期待結果に対して何度も繰り返し実行します。これはまさに自動化が得意とすることです。手動の回帰テストはリリースのたびに増えていく一方で、使える時間は増えないため、真っ先に削られてしまいます。CI 上の自動回帰テストスイートがあれば、「何か壊していないか？」という問いへの答えが、1 週間の手動確認からパイプラインの結果に変わります。

よくある間違い

• スイートを追加専用として扱う。 不要になったテストや重複したテストは、毎回の実行を遅くします。見直して削りましょう。
• フレーキーテストを容認する。 失敗をグリーンになるまで再実行するのが習慣になると、本物のリグレッションも再実行で見過ごされてしまいます。
• UI 経由でしかテストしない。 回帰テストのカバレッジの大半は、ユニットや API のレベルで実現したほうが安価で安定します。