変更量は出発点ではなく補助情報

回帰テストの範囲は、どれだけ多くのコードが変わったかより、その変更が誤っていた時にどこまで影響し、どれだけ遅く発見され、どれだけ戻しにくいかで決めるべきです。

変更されたファイル数やコード行数を無視しようという意味ではありません。変更量はレビューと検証に必要な作業量、変更の複雑さと不確実性を見積もる補助情報です。しかし影響範囲を決める出発点としては不十分です。ISTQB も回帰テストの前に影響分析を行うよう説明し、範囲を決める際に変更リスク、既存システムの大きさ、変更の大きさを併せて考慮します。[2][6]

一行の権限条件の変更が複数ロールのアクセス統制を壊すことがあります。逆に数百行のコードが変わっても、外部インターフェースがそのままで独立した内部モジュールに閉じているなら、必要な回帰範囲は比較的狭くなります。

回帰範囲を決める時に問うべき質問はこうです。この変更が誤っていたら、どのユーザー行動、権限、データ、連携が誤りうるか。その失敗はどれほど大きな結果を生み、私たちはどれだけ早く気づいて戻せるか。

これを概念的に整理すると、回帰範囲 = 影響の到達範囲 × 失敗結果 × 変更の不確実性 × 統制難易度です。この式は数字を掛けて点数を作れという意味ではありません。検討すべき問いの順序を表します。

影響候補を探す作業と実行範囲を選ぶ作業は別

回帰テストの選定には異なる二つの段階があります。第一は、何が影響を受けうるかを探す作業です。要求事項、変更、コード、テスト、欠陥の間のつながりをたどって影響候補を作ります。第二は、その候補のうち今回の変更でどのテストを実際に実行するかを決める作業です。この記事は第二段階だけを扱います。

影響候補に含まれたからといって、すべてのテストを実行しなければならないわけではありません。逆に、直接のつながりが見えないという理由だけでテストを除外することもできません。共通コンポーネント、権限ポリシー、データフロー、外部システムのように間接影響の大きい境界があるからです。

ISTQB の Test Analyst シラバスも、ひとつの選択技法がすべての状況で優れているわけではないと説明しています。リスクベース選択、過去の欠陥履歴、使用パターン、カバレッジと影響分析を状況に合わせて組み合わせなければなりません。[1][7]

サービスの仕組み

実行結果の信頼を保つ保守 — 変更に強い識別子で実行し、失敗原因を分類・修正して結果を再検証します。

回帰範囲を三つの水準に分ける

この記事では回帰範囲を Focused Regression、Expanded Regression、Broad / Release-level Regression の三水準に区分します。三水準の定義は下のとおりです。

Broad Regression がすべてのテストを無条件に実行するという意味ではありません。この水準でもリスクと関連性の低いテストは除外できます。違いは、特定機能の周辺ではなくリリース全体の重要な失敗境界を範囲とする点にあります。[3]

Focused Regression
Focused Regression は、変更が実際に局所化されているという根拠がある時に使います。変更された動作、直接つながる利用側、代表的な正常・失敗フロー、関連する過去欠陥テストを確認します。コミットが小さいという理由で選ぶ水準ではありません。
Expanded Regression
Expanded Regression は、変更がひとつの重要なユーザージャーニーや権限・データ・連携の境界に触れるが、影響範囲が特定領域に限定される時に使います。影響を受けるジャーニー全体と主要な例外フロー、ロール、データ状態、外部連携の分岐、共通コンポーネントの既知の利用側を含めます。
Broad / Release-level Regression
Broad / Release-level Regression は、複数の中核ジャーニーの共通境界が変わったか、失敗影響が大きく発見・復旧が難しい時に使います。中核ジャーニー群、ロールと権限の組み合わせ、主要なデータライフサイクル、外部連携、環境・設定の差異までリリース水準で確認します。

Change Impact × Regression Scope Matrix

下の Matrix は回帰テスト数を計算する採点表ではありません。各軸を検討した後、根拠のある最も高い水準を今回の変更の回帰範囲とします。軸は三グループです。影響の到達範囲が五軸、変更の性質と不確実性が四軸、失敗結果と統制可能性が三軸です。

実際の使用パターンを使った回帰選択は、頻繁で重要な業務プロセスを優先させます。認証・認可は正常ログインだけでなく、ロール間アクセスと水平・垂直の権限昇格まで確認しなければなりません。データ変更は CRUD ライフサイクル、整合性、アクセス統制と一貫性の問題につながりえ、外部連携はデータ変換・通信フロー・プロトコル・End-to-End 機能まで見なければなりません。[7]

過去の欠陥履歴は「欠陥が多かったコードだから必ず危険だ」という烙印ではありません。類似変更で実際に欠陥を見つけたテストと敏感に反応した領域を再び選ぶ根拠です。逆に、記録がないという事実だけで低リスクを証明することはできません。ISTQB は、過去の実行で欠陥を明らかにしたか類似変更に敏感だったテストを回帰範囲に含める History-based Testing を提示しています。[7]

設定変更も、コード変更より小さく見えるという理由で狭く扱ってはいけません。Google SRE が公開した事例のように、全域設定は想定外の依存と相互作用で広範な障害を起こします。[8]

検知可能性とロールバック難易度は回帰テストそのものの機能分類ではありませんが、検証範囲を決める時の重要な統制条件です。失敗を素早く見られないか、誤った変更を戻しにくいなら、運用で見つけるという仮定に頼るより事前範囲を広げるべきです。Google SRE は実トラフィックでだけ現れる問題と不明瞭な Canary シグナルを説明し、検証していないロールバック手順が障害時間を延ばした事例も公開しています。[8][9]

ロールバック可能なデプロイを実際に実装する方法は、別のデプロイアーキテクチャの問題です。ここではロールバックが難しいという事実を回帰範囲の上方シグナルとしてだけ使います。

グループ
評価軸
Focused Regression
Expanded Regression
Broad / Release-level Regression
影響の到達範囲Critical User Journey変更が非中核・単一段階に限定される。該当動作と前後のフローを確認する。ひとつの中核ジャーニーか主要な例外分岐が影響を受ける。該当ジャーニー全体を確認する。複数の中核ジャーニーの共通の入口・出口・状態遷移が変わる。関連する中核ジャーニー群を確認する。
影響の到達範囲Permission / Authentication権限規則・セッション・認証トークンに変化はなく、特定ロールの表示・動作だけが変わる。特定のロール・リソース・行為、またはログイン・セッションのフローが変わる。ロール間の許可・拒否と否定ケースを含める。中央の認証ミドルウェア、SSO、セッションポリシー、共通の権限モデルが変わる。関連ロールと中核行為をリリース水準で確認する。
影響の到達範囲Data Mutationデータの保存状態を変えないか、独立した照会・表示だけが変わる。ひとつのエンティティに生成・更新・削除、検証、マッピングの変化がある。該当データのライフサイクルと失敗処理を確認する。スキーマ・マイグレーション・共通トランザクション・重複処理・エンティティ間整合性が変わる。複数のジャーニーとデータ状態を含める。
影響の到達範囲External Integration契約・認証・データマッピング・再試行条件はそのままで、ローカルアダプタの内部だけが変わる。ひとつの外部連携で契約、認証、マッピング、タイムアウト、Webhook、失敗処理が変わる。成功・失敗・再試行のフローを確認する。共通 Gateway、複数のプロバイダ、共有契約、戻しにくい外部副作用が変わる。End-to-End の連携群を確認する。
影響の到達範囲Shared Component利用箇所がひとつか、境界が明確に隔離されている。複数の既知の利用側が使う共通モジュール・コンポーネントが変わる。主要な利用側を含める。認証・検証・ルーティング・共通 UI・共用ライブラリのように複数の中核ジャーニーが依存する中央コンポーネントが変わる。
変更の性質と不確実性Configuration特定機能やひとつの環境にだけ適用される局所設定で、境界が明確。環境・Tenant・Region・Feature Flag により別の経路が開く。代表的な設定の組み合わせを確認する。全域のルーティング・セキュリティ・権限・トラフィック・共通ポリシー設定が変わるか、隠れた依存が不明確。
変更の性質と不確実性Dependency実行動作やインターフェースが変わらない隔離された修正。直接 Dependency のバージョン・契約・直列化・呼び出し方式が変わる。主要な利用側と契約を確認する。複数サービスが共有するランタイム・ライブラリ、推移的 Dependency、メジャーバージョン、互換性が不明確な変更。
変更の性質と不確実性Change Noveltyチームが繰り返してきた慣れた変更で、類似変更の検証根拠がある。初めて実装する分岐・連携・状態、または不慣れな技術を含む。新しいアーキテクチャ・ランタイム・データフローのように比較する過去根拠がほとんどなく、実入力での動作が不確実。
変更の性質と不確実性Historical Defect Evidence類似変更と代表テストの最近の結果が安定して蓄積されている。似た変更で欠陥が起きたか、特定テストが繰り返し敏感に反応した。同一領域で回帰欠陥が繰り返されるか、複数コンポーネントにまたがる構造的欠陥の履歴がある。
失敗結果と統制可能性Failure Impact失敗が即時復旧できる不便にとどまり、権限・金銭・機微データ・中核業務に影響しない。中核ジャーニーの停止、復旧可能なデータ誤り、業務遅延や一部顧客への影響がありうる。不正アクセス、金銭誤り、データ整合性・個人情報・規制の問題、広範なサービス停止につながりうる。
失敗結果と統制可能性Detectability失敗結果が即時に現れ、テスト判定と運用シグナルが明確。誤りが遅延したり間欠的で、一部のユーザー・ロール・データ状態でだけ現れる。静かなデータ破損、権限露出、重複処理のように表面上は成功に見えるか、現在の観測では識別しにくい。
失敗結果と統制可能性Rollback Difficulty変更が局所的で状態を残さず、検証済みの方法で即時に戻せる。データ再処理、キャッシュ整理、外部システム調整など追加の復旧手順が必要。不可逆なデータ変更、外部副作用、長時間の復旧、検証されていないロールバックが予想される。
Change Impact × Regression Scope Matrix — 三グループ 12 軸と水準ごとの判定条件

点数を平均せず、最も強い根拠で範囲を上げる

12 軸に低・中・高の点数を付けて平均する方式は簡単に見えますが、重要なリスクを希釈します。権限変更ひとつが他の軸の低リスク複数と平均されて低い等級になってはいけません。データ整合性や戻せない外部副作用も同じです。

そのため範囲は下の四つの規則で選ぶ方が良いのです。

1. Focused は既定値ではなく「隔離された」という結論
コミットが小さいから Focused を選ぶのではありません。ユーザージャーニー、権限、データ、連携、共通コンポーネントに影響がなく、失敗を容易に発見・復旧できるという根拠が必要です。
2. 最も強い上方要因に従う
中央の権限モデルや共有データ層を変更したなら、他の項目が単純でも Broad になります。
3. 軸どうしの相互作用を見る
外部連携の変更だけなら Expanded かもしれません。その連携がデータを生成し、重複処理が金銭結果を生み、失敗の発見が遅く、ロールバックも難しいなら Broad に上がります。
4. 分からない状態も範囲を広げる根拠
Dependency の実際の利用側、構成変更の影響、外部システムの失敗挙動が分からないなら、その不確実性を低リスクとして処理してはいけません。追加分析で境界を確認するか、より広い範囲を選びます。

小さな変更が Broad Regression を要求する場合

権限条件を一行修正した場合を見ます。コード変更は一行かもしれません。しかし共通の権限ミドルウェアの条件なら、複数のロールと中核行為が影響を受けます。この変更は Permission / Authentication、Shared Component、Failure Impact、Detectability の軸に触れます。関連ロール別の許可・拒否、水平・垂直の権限移動、セッション状態と中核行為を含む Broad Regression が妥当です。

外部 Webhook の再試行設定だけを変えた場合も同じです。設定ファイルの値ひとつを変えても、外部イベントがデータを生成したり状態を変えたりするなら、重複実行、順序逆転、部分失敗が生じます。ひとつの連携と限られたデータにだけ影響するという根拠があれば Expanded から始めて構いません。同じポリシーが複数の連携で共有されるか、金銭・注文・精算のように戻しにくい結果があるなら Broad に上げます。

サービスの仕組み

製品の文脈を保ち、実行規模を調整 — 固定リードが基準と履歴を引き継ぎ、期間ごとのスクワッドの実行結果を判断の根拠にまとめます。

大きな変更が必ずしも Broad Regression を意味しない場合

独立した内部レポートモジュールを大規模にリファクタリングしたが、外部インターフェース、権限、保存データ、共通ライブラリ、ユーザーの中核フローは変わっていないと仮定します。変更されたコード量が多くても、影響境界が明確で結果を容易に比較でき、ロールバックも単純なら、Focused または Expanded Regression で十分です。

ただし「独立している」という判断は推測ではなく、依存と利用側の確認で立証しなければなりません。大きな変更量は検討作業と不確実性を高めますが、それ自体が Broad の自動条件ではありません。[4]

範囲選択の結果は簡潔な決定記録に残す

回帰テストの一覧だけを残すと、次の変更で同じ議論を繰り返すことになります。今回何を含め、なぜ除外したかを併せて記録しなければなりません。下の七項目で十分です。

実行中に新しい失敗、文書化されていない利用側、想定外のデータ状態が見つかったら、最初に決めた範囲を固定しません。範囲選択はテスト開始前に一度書いて終わる計画ではなく、新しい証拠に応じて更新される判断です。[5]

項目
記録する内容
変更何が変わったか。コミット・PR・設定変更の識別子
影響候補要求事項、変更、コード、テスト、欠陥のつながりをたどって見つけた影響候補
範囲を上げた軸12 軸のうち Expanded または Broad と判定された軸とその根拠
選んだ範囲Focused | Expanded | Broad / Release-level
含めたテスト今回の変更で実際に実行すると決めたテスト
除外したテストと根拠候補だったが実行しないと決めたテストとその理由
実行中に範囲を広げる条件新しい失敗、文書化されていない利用側、想定外のデータ状態が見つかった時の対応
Regression Scope Decision Record — 変更 1 件に残す 7 項目

変更量は作業量を語るが、リスクの方向までは語らない

コード行数とファイル数は、検討にかかる時間と複雑さを見積もるのに有用です。しかしユーザーがどの作業に失敗するか、権限とデータがどう変わるか、外部システムと共通コンポーネントにどこまで広がるかまでは教えてくれません。

回帰テストの範囲を決める問いは「どれだけ多く変わったか」ではありません。この変更が誤っていた時にどこまで壊れうるか、私たちはその失敗をどれだけ早く発見し、安全に戻せるか、です。

その答えが局所的で明確なら Focused Regression を選びます。ひとつの重要な境界につながるなら Expanded Regression を選びます。複数の中核ジャーニーの共通境界、大きな失敗結果、低い検知可能性や難しいロールバックが重なれば Broad / Release-level Regression に広げます。

こうして選んだ回帰結果はリリース判断の重要な証拠になります。しかし回帰テストを広く実施したという事実だけでリリース可否が決まることはありません。