変更別リグレッションテスト範囲決定ワークブック

回帰範囲の出発点は、修正ファイル数ではなく変更した要求とその影響です。変更番号と理由、変更前後の要求の版、対象ビルドとテストの版を先に書きます。表示文言だけを変えたのか、利用者の権限やデータの解釈を変えたのかが分かる必要があります。複数の変更をまとめて出すなら、それぞれの番号と共通して影響する境界をつなぎます。期限と環境の制約も記録しますが、リスクが低い根拠としては使いません。

このワークブックが作るのは、実行するテストの一覧と除外理由です。選定表を埋めても、テストが実行されたりリリースが承認されたりしたことにはなりません。変更リスクから範囲を選ぶ考え方は回帰テスト範囲のインサイトで説明しています。この資料では、変更概要、影響候補、範囲決定、実行・除外記録、引き継ぎ表にその判断を適用します。

複数の画面やAPIが同じ権限ポリシーを使う場合や、一つのファイルを複数のシステムが読む場合は、修正した場所の外でも失敗が起こり得ます。変更要求から実装とテストをたどり、実装から呼び出し元と利用者の行動を逆に確認します。権限ポリシー、保存規則、検索とエクスポート、共通設定、外部連携は個別に見る境界です。影響候補表には接続の根拠、確認する失敗境界、検討結果と担当を書きます。

テストと要求がリンクされているだけでは、現行版の影響検討が終わったとは言えません。要求が変わった後に期待結果も更新されたかを確認します。リンクがなければ影響なしとせず、未確定として担当と確認時点を決めます。要求変更とテストのトレーサビリティは、候補の発見に使う接続の管理方法を扱います。候補を探すことと、その中から実行するテストを選ぶことは別の作業です。

範囲決定表には、影響の到達範囲、変更の不確実性、失敗の結果、検知と切り戻しの条件を記録します。Focusedは確認済みの独立した境界と隣接フロー、Expandedは複数の役割・連携・データ利用先にまたがるフローを検討します。BroadまたはRelease-levelは、リリースの重要な共通失敗境界を併せて見る段階です。この名前でテスト件数や合格基準が自動的に決まるわけではありません。

共通権限の変更が範囲を広げる根拠なら、他の低い点数と平均して弱めません。一方でコードの修正量が多くても、影響が独立したモジュールに収まる根拠があれば無関係なテストまで選ぶ理由は小さくなります。Broadも全テストの無条件実行ではなく、関連性が低い項目は理由を残して除外できます。重要なシナリオを時間やアカウント不足で実行できない場合は、低リスクの範囲に名前を変えず未検証条件として残します。

以下は記入練習用の架空の変更で、顧客の修正や実行結果ではありません。Aは閲覧・検索・ダウンロードが使う共通の文書権限ポリシーの変更です。複数の役割と組織境界に影響するという仮定でBroadを選び、別組織の文書閲覧、検索結果への露出、ダウンロード権限を候補に含めます。独立した統計画面の文言は、そのポリシーや影響データと接続していないことを確認した場合だけ除外します。

Bは、二つのシステムが読むエクスポートファイルに項目を追加する変更です。ファイル生成だけでなく、両システムの項目解釈と旧形式との互換性を含めたExpandedを検討します。利用先一覧が古ければ未確定項目を残し、確認前に影響検討を完了としません。Cは識別値・保存値・共通ロジックを変えない独立した表示文言の修正です。この条件を確認した仮定で、表示と隣接操作をFocusedの範囲に選びます。

実際のCで文言が業務コードや検索キーにも使われるなら、仮定は崩れます。範囲名をコピーせず、影響候補に戻ります。例で重要なのは選んだ段階より、その選択を可能にした条件です。選定したテストの結果欄は、実際の実行まで空欄にします。

段階を決めた後は、テスト番号、選定・除外・未確定の区分、判断根拠、実行準備を書きます。Aで別組織の文書閲覧を選んだなら、組織別のアカウントと対象文書が必要です。アカウントがないことを関連性が低い理由にしてはいけません。準備項目と担当、実行時点を記録し、リリース担当に未検証リスクを伝えます。独立した統計文言を除外する場合は、権限ポリシーとデータの接続を確認した資料を参照します。

過去に欠陥を見つけたテストや実際の利用フローも選定根拠になります。ただし、欠陥の記録がないだけで低リスクとは判断しません。連携とデータの状態を一緒に見て初めて意味を持つ検証もあります。共通ルールを、より速く再現しやすい層で確認できるなら方法を変えられますが、画面でしか観察できないリスクまでなくなるわけではありません。別の担当者が除外記録を読んでも同じ境界を理解できるか確認します。

実行・再検討の引き継ぎ表は、選定テストと実行回、対象ビルド・環境・実行番号、結果・欠陥・未検証条件、次の担当をつなぎます。PASS・FAIL・BLOCKED・NOT RUNは実行記録に使い、計画だけの項目を成功としません。ビルド・要求・設定が変われば変更概要へ、新しい依存関係や欠陥が見つかれば影響候補と選定根拠へ戻ります。以前の成功記録で新しい変更を説明できるかも確認します。

会議で使うREADY・READY WITH CONDITIONS・HOLDは、合意基準と実際の結果、未検証範囲と残存リスクを検討した別の判断です。結果はリリース判定メモ・シナリオ結果表につなぎます。提供PDFと編集用Excelは日本語版です。変更一覧、現在のテストカタログ、未確定の影響とリリース制約を準備すると、IXCのQAプロセス構築やQAアウトソーシングで実行範囲と役割を具体的に相談できます。