リテストとリグレッションテストの違いは？修正確認と影響範囲の特定
ソフトウェアの不具合修正が行われた際には、「本当に正しく修正できているか」と「修正作業により新たな不具合が生じていないか」を確認しなければなりません。つまり、目的の異なる2種類のテストが必要です。
この記事では、リテストとリグレッションテストの違いと、効率的なテストのために修正の影響範囲を特定するコツを解説します。修正後のテストをどのように実施すべきか悩んでいる方は、ぜひ参考にしてください。
不具合の修正確認が重要な理由
不具合が修正されたら、確実に動作確認まで実施する必要があります。確認を怠ると、修正漏れや反映ミスに気付かず、不具合が改善されないままのソフトウェアがリリースされてしまう恐れがあるためです。
また、修正による副作用で、今まで正常に動いていた別の機能に不具合が出る場合もあります。これを「デグレード」と呼び、テストで見逃してしまうとリリース後に思わぬ問題につながります。
修正確認の際は、改めて仕様書を確認しましょう。修正後のソフトウェアは、仕様として想定される動作やセキュリティ要件に合致していることが重要なためです。
リテスト（再テスト）とは
不具合が正しく修正されたことを確認するために行うテストを、「リテスト（再テスト）」といいます。リテストについて詳しく解説します。
リテストの目的
リテストは、不具合が本当に解消していることを確認する目的で行います。修正後に、不具合の報告時と同じ手順・同じ環境・同じデータで実施します。単にエラーが出なくなったかどうかだけでなく、本来あるべき動作になっているか、期待値に合致する出力が得られるかを確認することが重要です。不具合自体の再現率が100%ではなく低い場合、リテストの実施回数は複数回の実行になります。修正方法によっては最初に不具合が出たときよりも再現率が低下している可能性もあり、見つけにくい不具合になっているかもしれません。このようなことを考慮に入れ、リテストの回数を決める必要があります。
リテストの実施タイミング
開発者から修正完了の報告を受け、修正が反映されたバージョンのソフトウェアが用意されたら実施します。リテストは、リグレッションテストよりも優先して実施しましょう。もしかすると、その修正が完了したソフトでしか行えないテストがブロックされているかもしれません。そういった場合、早い修正確認とリリースを行わなければ、効率的なテスト実施ができなくなります。確認がとれたら不具合票のステータスを変更して、開発者に通知します。
リテストのポイント
リテストは、個々の不具合に対してピンポイントで実施するため、合格か不合格かの判定がはっきりしています。不合格となった場合は、開発者に差し戻して再度修正を依頼しましょう。
リグレッションテスト（回帰テスト）とは
リグレッションテストとは、不具合の修正によって他の箇所に影響が出ていないか（デグレードが発生していないか）を、広範囲に確認するテストのことです。「回帰テスト」とも呼ばれます。
大規模なシステムほど修正の影響範囲は広く複雑になる傾向があるため、リグレッションテストが欠かせません。
リグレッションテストを効率化しつつ、製品の品質を維持するには、テストツールによる自動化がお勧めです。これにより、リテストとリグレッションテストを並行して実施しやすくなります。リテストで不具合単位の修正確認を行いつつ、自動的なリグレッションテストでシステムの他の箇所に影響が出ていないことも確認できます。
不具合修正の影響範囲を特定する方法
限られた時間で効率良くテストを行うには、不具合の影響範囲を特定することが大切です。これにより、リグレッションテストの範囲を適切に設定できます。
方法1：開発者へのヒアリング
まずは修正を担当した開発者に、ソースコードの変更箇所から導かれる影響範囲を確認しましょう。これにより、仕様書中のどの機能をリグレッションテストの対象に含めるべきかを、技術的な視点から洗い出せます。
方法2：関連機能の洗い出し
修正した機能と連携する画面や処理があれば、それらも間接的に影響を受けると考えて、リグレッションテストの対象としましょう。このとき、データの流れを意識すれば、影響範囲が見えてきます。
方法3：リスクベースの優先度付け
影響のある全ての機能を確認する工数がない場合は、優先度を設定して対応しましょう。製品のコアとなる機能やユーザーがよく使う画面、過去に不具合が多かった箇所などを優先的にテストします。これらが仕様通り動作することを常に確認していれば、テストを効率化しつつ、重大な問題にも気付きやすくなるでしょう。
方法4：非機能面（パフォーマンス・負荷）の確認
修正機能が正しく動くだけでなく、処理スピードや負荷耐性といった非機能面への影響も考慮しましょう。不具合の修正内容によっては、意図せず処理が重くなったり、メモリを余計に消費したりして、パフォーマンスが低下（デグレード）してしまうケースが多々あります。
特に、システムの応答速度や同時接続数など、仕様として厳格に定められた制約がある場合は注意が必要です。これらの数値目標をクリアできているか、リグレッションテストの項目として改めて確認するようにしましょう。
まとめ
不具合の修正確認を行う際は、リテストとリグレッションテストを適切に組み合わせることが重要です。これにより、不具合そのものの修正を確認しつつ、デグレードも防止できます。また、修正による影響範囲を把握すれば、テスト工数の削減も可能です。ツールなども使いながら効果的なテストを効率良く実施して、製品の品質維持に努めましょう。