回帰テストの優先順位はどう決める？修正後の確認範囲と計画の作り方

中小企業で業務システムの修正版を受け取り、開発会社との確認を取りまとめる方へ。納品書の不具合を直したと連絡が来ても、請求書や出荷ラベルまで同時に試す時間がなければ、何を先に確かめるか迷います。直した例だけを見ると、同じ部品を使う別の仕事への影響を見落とすことがあります。

直した例の確認と、変えていない仕事の再確認を分け、変更とのつながりを示す資料と業務への影響から順序を相談します。関係が分からない仕事は照会先を残し、後に行う通常の確認も計画から消しません。この記事では、架空の部品卸の6つの仕事を使い、選んだ理由・担当・不足資料を一組の確認計画へまとめます。試験結果はすべて未実施です。

不具合の修正確認と回帰テストは何が違う？

今回直すのは、納品書PDFで住所2行目が欠ける不具合です。PDFは印刷用の文書ファイルで、この例では納品書・請求書などの出力に使います。開発窓口の変更メモには、共通のPDF部品と住所の表示処理にも修正があると書かれています。

最初に、住所が2行の納品書を同じ条件で作り、宛先と住所2行目が原注文に対応して欠けないか確かめる予定を置きます。これは「直した不具合が解消したか」の確認です。それとは別に、変えていない請求書や通常の納品書を試す計画を作ります。

変えていない仕事を改めて試すことを、回帰テストと呼びます。名前を覚えるより、「修正で別の仕事を壊していないか」と考えると目的が分かります。この区別と変更の影響を調べる考え方は、ISTQBのテスト基礎シラバス v4.0.1の§2.2.3・§2.3に基づきます。以下の6業務や順位は独自の架空教材です。

試す操作や期待する結果そのものが決まっていない場合は、先に発注者の受入テスト確認表で通常・入力違いなどの動作を合意してください。この記事は、既存の仕事から今回先に試すものを選ぶ段階を扱います。

修正していない請求書も要確認？共通部品から影響範囲を調べる

開発窓口から変更メモと構成メモを受け取り、仕事ごとの業務手順と結びます。構成メモは、どの仕事がどの部品を使うかを説明する資料です。画面や帳票の名前が違うだけで、変更と無関係とは判断できません。

この教材の「請求書と共通PDF部品の構成メモ」には、請求書も納品書と共通のPDF部品を使うとあります。請求書テンプレート自体を変えていなくても、修正した部品を使うなら再確認の候補になります。「出荷ラベルと住所表示の構成メモ」では、住所表示の処理を納品書と共有しています。通常の住所1行の納品書も、修正した納品書テンプレートを使います。

反対に、受注登録の構成メモには別の登録経路とあります。この資料の範囲では、今回のPDF・住所表示との直接関係は示されていません。それは、受注登録を試さなくてよいという証明ではありません。関係の強さと、仕事の重要さを別々に残します。

仕入先向け発注書は業務手順があるものの、構成資料は未入手です。PDFらしい名前から共通部品を使うとも、使わないとも決めません。購買担当と開発窓口へ、どの部品を使うか、対象条件は何かを聞きます。未入手資料の中身を教材で補うことはしません。

どの業務からテストする？変更の影響と業務リスクで優先順位を決める

関係資料を読んだら、業務窓口が仕事の影響を持ち寄り、責任者と開発窓口で順序を相談します。たとえば、請求書が作れないことと通常の納品書が読みにくくなることでは、今回の業務への影響が違います。資料の関係だけで一律に順位を付けず、担当に何が止まるかを確認します。

次の表は、架空の責任者が今回選んだ計画です。直した住所2行の納品書を最初に確認する予定と、変えていない仕事の再確認の組を分けています。実際の確認日・環境は未定で、どの行もまだ試していません。

この例では、修正箇所の確認後に、請求書、出荷ラベル、住所1行の納品書という順で先の再確認を組みました。これは架空の責任者の判断で、すべての会社に使える順位ではありません。手元の資料と担当者の業務影響が違えば、理由を残して相談し直します。

請求書・発注書のテスト順は？共通部品と不足資料から考える

請求書のテンプレートを変えていなければ、先の確認から外せるでしょうか。この教材では共通PDF部品を使う記録があります。テンプレートの変更有無だけで外さず、共通部品との関係と、請求担当が資料を作れなくなる影響を見て、先の組に残します。

発注書の構成資料がない場合はどうでしょうか。関係が分からない状態を、対象外や問題なしには変えません。開発窓口へ不足資料と共有部品の確認を依頼し、その回答を受けて順序を相談します。問い合わせを残すことと、試験を実施することは別です。

試験の選択や順序に業務上のリスクを使う考え方は、同シラバスの§5.2.3でも説明されています。ただし、この記事の判断は完全なリスク分析や全試験範囲の網羅を保証するものではありません。性能や権限など、合意済みの別の確認をこの6行で置き換えないでください。

後回しのテストを忘れないために｜担当・確認予定・不足資料を残す

自社の変更1件について、変更内容と対象版、試す環境と予定時期、計画を相談する責任者を残します。その上で仕事ごとに、期待する動き、関係の根拠資料、止まる影響、順序と選んだ理由、担当、未確認事項を記入します。

「後で確認」は、対象を消す意味ではありません。受注登録のように日常業務として重要な仕事には、確認予定と担当を残します。発注書のように関係が不明な仕事は、資料の照会先と、返答後に誰が順序を決めるかを残します。先の組が通ったとしても、後の仕事まで成功したとは報告しません。

この架空例には、納品書の住所2行目の変更メモ、4つの構成メモ、6つの業務手順があります。発注書の構成資料は未入手です。計画と確認結果を分け、試験前の計画を成功記録にはしません。

まとめ：修正箇所・影響範囲・業務リスクからテストの順番を決める

まず、今回直した箇所と、同じ部品を使う別の仕事を開発窓口へ確認してください。次に、業務が止まる影響を担当と相談して先の確認を選び、後の通常確認と関係資料の照会も一緒に残します。選んだ理由が読める計画を責任者と開発窓口へ渡すことが、今日の一歩です。

これは試す前の計画です。結果を記録する段階では、テスト結果と原本を結ぶ保存表とは作業が異なります。実際に試した結果は自社の記録へ別に残し、未実施を成功に変えないでください。

変更と仕事の関係が分からず相談が必要な場合は、DREEXYの業務整理・連携支援を確認し、変更メモ・既存業務の一覧・不足資料を用意して相談窓口へ渡せます。支援の範囲や担当は個別に確認します。