システムの開発が進むにつれて、システムはより複雑に、規模はより大きくなっていきます。その結果、機能の追加や変更などによる影響範囲の特定が難しくなり、プログラムの変更時にシステムに対して意図しない影響（デグレ・リグレッション）を生じさせるリスクが高まります。
そういったリスクを軽減するためには、デグレを検出するためのテストであるリグレッションテスト（回帰テスト）を実行する必要があります。

本記事では、システム開発の品質保証において欠かせないリグレッションテストについて、JSTQBのシラバスや実際の事例を交えながら、概要からその目的、重要性、実施におけるポイントについて、ご紹介いたします。

なおデグレについては、当コラムのデグレ（デグレード）とは｜デグレのリスクや原因、対策で詳しくご紹介しています。デグレについて知りたい方は、ぜひ合わせてご参照ください。

リグレッションテスト（回帰テスト：Regression Testing）とは

リグレッションテストとはソフトウェアテストの一つであり、機能の追加や変更、不具合の改修などに伴うプログラムの変更によって、その他のプログラムに意図しない影響が発生していないかどうかを確認するテストです。

デグレとは「プログラムの変更によって生じる意図しない影響」のことを指す和製英語で、英語ではリグレッション（Regression）と言われます。
リグレッションテストはデグレ（リグレッション）の発生有無を確認するためのテストであることから、そのような名称となりました。
またリグレッションテストは「回帰テスト」「退行テスト」と呼ばれることもありますが、これはリグレッションが日本語で「回帰」や「退行」を意味するためです。

また、JSTQBの『テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03』では、リグレッションテストは以下のように定義されています。（ISTQBおよびJSTQBでは、「デグレ」ではなく「リグレッション」という単語を使用しています）

つまり、リグレッションテストとはプログラム変更に伴う意図しない副作用＝デグレ（リグレッション）を検出するために実行するテストであると言えます。

また、リグレッションテストにはシステムが成長し規模や複雑性が増すにつれて、その重要性が増大するという特徴があります。

リグレッションテストを実施しないことのリスク

リグレッションテストはデグレを検出するために行なう重要なテストであることをご紹介しましたが、もしリグレッションテストを実施しなかった場合、どのようなリスクがあるのでしょうか。

デグレにより、システムの信頼性が損なわれる

プログラムの変更により、それまで動作していたシステムに不具合が生じた場合、変更前よりも品質が悪化することになります。
システムの規模や複雑性が増大しやすい傾向にある昨今において、プログラム変更の影響範囲がますます見えにくくなるなか、デグレの発生リスクは常に存在していると言えます。
それにもかかわらずリグレッションテストを行わない場合、プログラムを変更するたびにデグレが発生しうるリスクを放置することとなり、重大な不具合が生じるまで気づかずに新たな不具合を作り続けてしまうということにもつながります。

その結果、開発を進めれば進めるほどシステムの信頼性が損なわれるという負のスパイラルに陥ってしまう可能性があります。
システムの信頼性が損なわれれば、社内外のプロジェクト関係者だけでなくユーザーにまでその影響が波及する可能性もあり、ひいては会社の信用問題などにも発展しかねません。

結果的に、より大きな工数・コストがかかることがある

リグレッションテストの実行には当然相応の工数・コストがかかりますが、リグレッションテストを行わずデグレの検出が遅れてしまうと、早期に検出した場合に比べて不具合の修正コストが大きく跳ね上がってしまう可能性があります。
基本的に、ソフトウェアテストにおいて不具合はなるべく早期に検出した方が修正コストを抑えることができ、逆に検出が遅くなればなるほどそのコストは高くなる傾向があります。
なぜかというと、早期であれば不具合の影響範囲は比較的限定されている可能性が高く、また不具合の原因特定も容易ですが、検出が遅れれば遅れるほど影響範囲が広がる可能性があり、その原因特定も難しくなることが多いためです。

実際の事例として、弊社SHIFT ASIAが結合テストレベルのソフトウェアテストの担当として参画したプロジェクトにおいて、前のレベルにあたる単体テストレベルの不具合が結合テストで多数検出されるということがありました。
その主な原因はコーディングや詳細設計におけるミスや、単体テストが適切に行われていなかったことにあったのですが、結果として単体レベルにまでさかのぼって原因の特定や修正を行ったことから大掛かりな修正作業が発生しました。その結果、結合レベルにおけるシステムとの新たな不整合が発生したことは言うまでもありません。

最悪なケースとしては、デグレによる不具合が納品のタイミングや、リリース以降の運用フェーズで見つかることもあり、その場合は単なる修正コストだけでなく、補償などのコストも発生する可能性があります。

不具合の検出タイミングとコストの関係については、当コラムのバグの早期検出メリットとその方法｜インスペクションのすすめでご紹介しています。宜しければ、合わせてご参照ください。

このように、リグレッションテストを実施しないことによるリスクは時に大規模な問題にも発展しかねないことから、相応のコストをかけてでもリグレッションテストを実施することがリスクを抑えるためには重要です。

リグレッションテストの実施におけるポイント

リグレッションテストが様々なリスク抑止につながる一方で、リグレッションテストにそこまで大きな工数・コストをかけられる余裕がないというプロジェクトが多いのではないでしょうか。
そこで、次に効率的にリグレッションテストを実行するための4つのポイントについてご紹介します。

１.重要度に応じて優先順位をつける

他のソフトウェアテストと同様に、基本的には範囲を広げれば広げるほどテストケース数・工数・コストは大きくなります。ですので、基本的には重要な機能やフローが仕様通り動作することを重視し、それらに関わる範囲を対象としたリグレッションテストを行うことが効率的です。

フルリグレッションテストと呼ばれる、範囲を限定せず一通りのリグレッションテストを行う方法もありますが、よほどミッションクリティカルなシステムかつ重大なデグレが多数発生しているなど、特別な場合を除いて行なうべきではありません。費用対効果が見合わないことが多いため、重要度に応じた重みづけを行うことが効率化には有効です。

例えばECシステムであれば、会員登録やログイン、商品選択から決済といった極めて重要な一連のフローをリグレッションテストの対象とするなど、システムやビジネスにとって重要性の高い部分にフォーカスするといった形です。
一方で重要性の低い部分はテスト範囲には含めないなど、取捨選択を行うことが効率的なリグレッションテストを実施するための肝になります。

2.何度も実行し、少しずつ拡充をしていく

JSTQBによれば、「リグレッションテストスイートは何度も実行し、通常は少しずつ拡充をしていく」ことが推奨されています。また何度も実行をすることから「自動化による効果が非常に大きい」とも言われています。
リグレッションテストを繰り返し行い、機能の拡張と合わせてテストケースを拡充していくことで、システムに対する信頼の積み上げをはかることができます。

ソフトウェアテストの7原則の一つである「殺虫剤のパラドクス」では、同じテストを何度も繰り返すことは次第に効果が低減するので意味が薄いと言われていますが、自動化されたリグレッションテストにおいてはリグレッション（デグレ）の低減という結果が得られるので有益だとされています。

実際に、デグレの特性上ある時点では問題なく動作していても、その後のある時点で正しく動作しなくなるということがあり得るため、拡張しながらテストを何度も繰り返すことによってその信頼性が高まると考えられます。

3.すべてのテストレベルで行う

リリース前の受入テストで実施することはもちろんですが、JSTQBによれば「リグレッションテストは、すべてのテストレベルで行う」ことが推奨されています。
つまり「単体テスト」「結合テスト」「総合テスト（システムテスト）」の各テストレベルにおいて、プログラムの更新や不具合の修正時に実施することが望ましいと言えます。
その理由は、仮にデグレが発生したとしてもなるべく影響範囲が限定的な早期のうちに検出・修正をするためです。

しかし、プログラムを変更するたびに毎回手動でリグレッションテストを実行することは、工数や時間の面から現実的ではありません。
そこで、特に何度も繰り返すリグレッションテストについては、テストを自動化することがおすすめです。

実際に弊社がリグレッションテストを担当した案件では、各テストレベルにおいてまずはテストを設計しマニュアルで実行、検出した不具合を修正後にテストの一部をリグレッションテスト用に再設計した上で、それを自動化してビルドのたびに繰り返し実行するということを行っていました。
結果として、そのプロジェクトではプロダクトのリリース後の重大な不具合は一度も発生しませんでした。

4.なるべく早期にリグレッションテストの自動化を開始する

同じくJSTQBによれば、「リグレッションテストの自動化はプロジェクトの早期に開始すべきである」とあります。
リグレッションテストの多くは何度も繰り返し行うことが求められる性質上、いつまでも手動テストでの実行を続けることはコストの面でも時間の面でも大きな負担となります。

もしリグレッションテストを自動化すれば何度も繰り返すテスト実行のコストや時間を大きく削減できることから、自動化にかかる実装や運用のコストを吸収しやすく、中長期的に大きなメリットが期待できます。
テスト自動化のコストとメリットの考え方については、当コラムのテスト自動化とは｜テストを自動化するメリットと注意点でも紹介しておりますので、宜しければ合わせて参照ください。

テスト自動化は特に単体テストと相性が良く、ビルドのタイミングで都度自動テストを実行することでデグレの早期検出にも役立ちます。もちろん複数の機能が関わる結合テストや、一連の動きを確認するシステムテストでも有効です。
いずれの場合でも、プロジェクトの早いタイミングでリグレッションテストが自動化できれば、テストの効率化やデグレの早期検出につながるので非常に大きなメリットがあります。

弊社がリグレッションテストを担当したある案件では、プロジェクトの当初からリグレッションテストの自動化が検討されており、クライアント側の体制も自動化の導入を前提に構築が進められていました。また、システム自体もテスト自動化を想定した作りとしていたことから、非常にスムーズにテスト自動化の導入と運用が進みました。

早いタイミングでリグレッションテストの自動化を開始するために、プロジェクトの計画段階から自動化を想定した上であらかじめ準備を進めておくことで、導入から運用まで効率的に進めることができた一例となります。

こちらはあくまでも一つの理想的な事例であり、ここまで入念に準備を進めるのは簡単ではありませんが、なるべくプロジェクトの計画においてリグレッションテストとその自動化についても視野に入れた計画を立てることで、リグレッションテストの効率および効果の向上につながると言えるでしょう。

最後に

システム開発においてデグレ（リグレッション）は常に起き得るものであり、そしてまた大きなリスクに繋がり得るものでもあることから、それを検出するためのリグレッションテストは非常に重要です。

しかし、いたずらにテスト範囲を広げ人海戦術的に多くのテストケースを実行すれば良いというわけではなく、効率的にリグレッションテストを行うことが肝であり、そのためには重要度に応じて範囲を設定した上で、なるべく早い段階で自動化することが推奨されます。

そして、基本的にはすべてのテストレベルにおいてリグレッションテストを実行し、もしデグレが発生しても早期に検出できる状態を実現することにより、リスクの拡大を抑制することが可能となります。

デグレによるリスクは時に非常に大きなものとなり得るという性質上、なるべくプロジェクトの計画段階からリグレッションテストおよびその自動化までを見据えることが、プロジェクト運営やシステムのさらなる安定化および信頼性・品質の向上につながると言えるでしょう。

SHIFT ASIAでは、リグレッションテストの計画や設計、実行および自動化について、これまでに多くのお客様のご支援をさせて頂いております。
「リグレッションテストの適切なやり方がわからない」「工数が十分に取れない」「もっとコスト・工数を効率化したい」などお困りのことがございましたら、ぜひSHIFT ASIAにお気軽にご相談ください。

SHIFT ASIAのソリューション：リグレッションテスト