ソフトウェアのある機能の不具合（バグ）を修正することで、想定しなかった新たなバグが発生することもあります。このような新しいバグがないか確認するために行われるのが、リグレッションテストです。この記事では、リグレッションテストとはどんなものかや、その重要性、行うべきタイミング等をまとめて解説しています。

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

リグレッションテストとは、プログラムの修正・変更後に欠陥があらたに入り込んだり、予想外の影響が生じていないかチェックするためのテストを指します。プログラムの修正や変更によって新たに生じる品質低下・バグのことを、「リグレッション」や「デグレーション」といいます。つまり、リグレッションテストでは、修正前に行ったテストをもう一度行うことによって、リグレッション・デグレーションが発生していないかを確認するわけです。

リグレッションテストのことを「回帰テスト」や「退行テスト」と呼ぶこともあります。
ソフトウェアは、さまざまな機能が互いに影響しあって動作しています。そのため機能の一部を修正することにより、その他の機能に想定しなかった影響が生じてしまうこともあり得るのです。ソフトウェアの規模が大きくなるほど、リグレッションテストの必要性も高くなります。

リグレッションテストとデグレーションテストの違い

プログラムの修正や変更によって新たに生じる品質低下、バグのことを「リグレッション」「デグレーション（デグレ）」と呼ぶことを解説しましたが、両者に違いはあるのでしょうか。
「リグレッション（Regression）」は、「回帰」という意味で、主に、昔に戻ってしまうことを言います。対して、デグレーションの語源「デグレード（degrade）」は、「劣化」という意味になり、主に品質が劣化する、悪くなることを指します。微妙な語源の違いはありますが、両者とも、なんらかの変更等により、品質が回帰したり劣化したりしていないかを確認するテストであるため、ほぼ同じ意味で使われています。

リグレッションテストの重要性

前述の通りプログラムの一部を修正すると、他の機能に想像もしなかったバグが生じることもあります。特に基本的な機能にバグが生じた場合は、ソフトウェアが正常に利用できなくなることから、その影響は小さくありません。

膨大なコストをかけて開発したソフトウェアでも、そういったバグを発見できずに顧客へ引き渡してしまったら、信頼を失うことは避けられないでしょう。リグレッションテストの実行には少なからず工数が必要となりますが、リグレッションテストを行わないことのリスクは非常に大きいのです。

リグレッションテストを行うタイミング

それではリグレッションテストは、どのようなタイミングで行うべきでしょうか。主なタイミングを1つずつ見ていきましょう。

バグを修正したとき

リグレッションテストが必要となるのは、まずバグを修正したときです。せっかくバグを修正しても、別の機能に影響が生じていないとは断言できません。そのためバグ修正後は、リグレッションテストを実施します。

各テスト工程の終了後

ソフトウェアテストの工程は、特定の機能をチェックする「単体テスト」からはじめるのが一般的です。その後、複数の機能が正しく連携するかチェックする「結合テスト」、ソフトウェア全体の動作をチェックする「システムテスト」と続きます。

これら各テストの工程でバグの修正が行われる可能性がありますが、それぞれのテストの後にリグレッションテストを行います。各工程で実施されたバグの修正により、これまで実施済みとなったテスト結果に変化が生じていないか確認するわけです。

ソフトウェアの変更があったとき

ソフトウェアに対して何がしかの変更が行われるタイミングは、バグの修正時だけではありません。既存機能のアップデートや仕様変更等で、プログラムが修正されることもあります。その際にも、その他の機能に予期しなかった影響が発生している可能性があるため、リグレッションテストが必要です。

リグレッションテストを行う範囲

リグレッションテストのなかでも、特に範囲を決めず全ての機能のテストを改めて実施することを「フルリグレッションテスト」と呼びます。フルリグレッションテストによって、全ての機能にバクが生じていないか確認できれば安心ですが、効率的とはいえません。

リグレッションテストで最も優先されるのは、各機能の基本的な動作 に影響が生じていないか確認することです。そのためリグレッションテストの対象となる一般的な範囲は、それを確かめるのに必要となる箇所までとなります。

なお一口に「基本的な動作」と言っても表現が曖昧ですが、これは機能等によって異なります。たとえば検索機能であれば、「検索ができる」ところまでを基本的な動作と判断する場合もあるでしょう。一方で、「and検索」や「or検索」ができるところまでを基本的な動作と判断することもあります。

このあたりの判断の差は、そもそものテストの粒度や、ソフトウェアにどのような修正が行われたかによってもかわってくるところです。一概に「ここからここまで」を、リグレッションテストをすべき範囲と結論付けることはできません。

リグレッションテストと自動化の関係

リグレッションテストは、専用ツールを使って自動化しやすいのも1つの特徴です。リグレッションテストでは、修正が行われていない機能がテストの範囲に入ります。そして、それら対象機能は基本的に、最初にテストを行った際と挙動が変わっていません。結果、同様のテストを繰り返すことになることから、自動化が向いているといえるわけです。

リグレッションテストを自動化することにより、テストの工数を大幅に減らすことができます。またテストの工数を抑制できることから、限られた人員でも必要なテストを省略せず行えるようになることも自動化するメリットです。

「リグレッションテストとは？」まとめ

ソフトウェアの各機能は連携していることから、個別の機能の修正が他機能に想定しなかった影響を及ぼすこともあります。そうしてソフトウェアの修正後は、別の機能に悪影響が出ていないか確認するための「リグレッションテスト」を行うことが必要です。仮にリグレッションテストを行わないと、顧客への引き渡し後に予期しなかったバグが発見され、顧客の信用を失ってしまうというリスクもあります。

なおリグレッションテストにおいて、改めてテストを全てやり直すことは効率的とはいえません。一般的には各機能の基本的な動作について、リグレッションテストで影響が出ていないかチェックするようにします。