リグレッションテストとは:デグレーションとの違いや範囲、自動化までを徹底解説
回帰テスト、退行テストとも呼ばれるリグレッションテストは、プログラムを一部修正した時に、修正がほかの部分に影響や不具合を与えていないかを調べるものです。
リグレッションテストをおこなうタイミングやおこなわないことのリスク、テストの自動化について解説しました。
システムやプログラムはシンプルな構造をしていません。さまざまな機能が関連しあって1つのシステムあるいはプログラムを構成しています。
そのため、どこか一箇所に変更をくわえると、それまで隠れていたバグが見つかったり、プログラムがうまく作動しなくなったりします。
また、新たなバグが発生した影響で連鎖的に各々の機能がかみ合わなくなってしまうケースもあります。
こうした懸念は、システムやプログラムの全体像が巨大になればなるほど発生するリスクが高まります。大きなプログラムになると、たとえ開発者であっても全貌をすべて把握することは難しく、修正した部分がほかの部分に大きな影響を与えてしまうことも珍しくありません。
こうした不具合を解消するため、システムやプログラムは修正した後には、必ずリグレッションテストを実施します。
デグレッションを検証するという意味において、リグレッションテストを「回帰検証」や「ノンデグレードテスト」ということもあります。
リグレッションテストの範囲は、主に次の3つのポイントを考慮して決定されます。
開発をスムーズに進めていくためには、リグレッションテストをおこなう一定の条件を設定し、範囲を絞り込む必要があります。 バグの影響する箇所と、それが関係するデータを扱う箇所にテスト範囲を限定することで、リグレッションテストの工数を減らし、効率よく開発を進めることができます。
そのため、影響範囲を正しく把握することが、リグレッションテスト範囲を決定する上で重要になってきます。
リグレッションテストの範囲決定において重要なポイント2つめは、デグレードが発生した場合のリスクレベルを、部分ごとに把握しておくことです。リスクが大きいと思われる箇所から、優先的にテストを実施していきます。
たとえば、不具合やバグが一部の機能やモジュールで限定的に関わっているのであれば、デグレードのリスクはそれほど高くないといえます。
一方で、システムやプログラムの基盤に深く関わってくるような箇所に関わるものであれば、そのリスクレベルは非常に高いといえるでしょう。
万が一不具合が生じた場合に、どの程度のリスクがあるのかをしっかりと把握しておくことで、適切にリグレッションテスト範囲を決めることができます。
上記のような場合、本来はテスト範囲を絞らずに降るリグレッションテストを実施するのが最善策ではありますが、現実問題として不可能な状況はあるでしょう。そのような局面ではすべてをテストなしに放棄してしまうのではなく、優先度の高い項目、範囲からテストをしていくことが必要です。
開発におけるテストは、一般的に次のような順序でおこなわれます。
そのため、ある時期まで使えていた機能が機能低下を起こし、突然使えなくなるという事態が発生する可能性があります。
また、顧客が運用していく過程で不具合が次々に発生する可能性もあります。
このような場合、顧客との信頼関係は崩れ去るでしょう。
システムやプログラムが作動しないと仕事が滞るので、企業全体に大きな影響が出てしまいます。
ちなみに、自動化ツールはある程度システム開発を進めた段階のみした導入することができません。開発の初期段階からリグレッションテストをすべて自動化できるわけではないので、注意しましょう。
単体テストは、1つの機能やビルド単位でおこなわれますが、このテストを自動化することでバグの多くを削減することが期待できます。
バリエーションテストは、異なる種類のデータを複数入力し、そのデータごとに結果をチェックしていくテストです。 バリエーションテストや、バグ修正ごとにおこなわれるテストのように、何度も実施しなければならないテストは自動化に適しています。
また、システムを修正した時に全体の動きに変化がないかどうかを確かめる保守テストも、システム作成後や修正後にその都度おこなう必要があるテストのため、自動化に向いています。
一方で、自動化ツールの選定やメンテナンス、テストの自動化そのものに工数とコストがかかることも考慮しておかなければなりません。 自動化するコストや工数と、リグレッションテストを自動化せずおこなう場合のコストと工数。それらを比較して置く必要があるでしょう。
ちなみに3〜5回程度おこなう必要性のあるテストは、自動化した方がコストがかからないというのが一般的な指標のひとつです。
ここに挙げた代表的なリグレッションテスト自動化ツールは、あくまで参考です。設計する際には、システム開発にもっとも適したリグレッションテストについても、事前によく計画しておく必要があるでしょう。
Firefoxのアドオンである「Seleniumu IDE」を活用することによって、
Firefox上のユーザーがおこなったアクションをスクリプトにすることができるなど、プログラミング言語に詳しくないビギナーにも使いやすい点が特徴です。
「Selenium WebDriver」は、Java、C#、Python、Rubyなど多言語のスクリプト作成に対応しています。
スケジューラー機能が搭載されているため、定期的なテスト実行を指示することも可能。ほかのツールと比較すると、トラブルが発生した際の対処法を見つけやすいという特徴があります。
ただし、Jenkinsの機能はあくまで実行命令のスケジューリングであるため、実際にテストを実行するには、プラグインを紐づける必要があります。
プログラムを動作させることなくソースコードからエラーを発見する「静的解析ツール」や、単体モジュールをテストするための「ユニットテストツール」といったプラグインを組み合わせることで活用できます。
1つのテストスクリプトで、iOSとAnadroidそれぞれに対応するという特徴があり、元のアプリのソースに手を加えることなくテストを実行できるというメリットを備えています。
Apache Jmeterは、パフォーマンスの測定、HTTPレスポンスの妥当性をチェックすることができるため、機能テストを実施することもできます。
テスト結果はグラフで表示させたり、メールでデータを送信したりできます。
開発の当初からしっかりと計画を立てて、効率的にテストをおこなえるようにしていくことが肝要です。
リグレッションテストをおこなうタイミングやおこなわないことのリスク、テストの自動化について解説しました。
- リグレッションテストとは?
- リグレッションテストとデグレーション
- リグレッションテストの範囲を決めるポイント
- リグレッションテストの実施タイミングとは
- リグレッションテストをおこなわないリスク
- リグレッションテストはツールで自動化できる:そのメリットと適性
- リグレッションテスト自動化ツール
リグレッションテストとは?
リグレッションテスト(Regression test)は、日本語で回帰テスト、退行テストともいいます。 プログラムの一部を修正した時に、その影響でほかに不具合が出ていないかをチェックするためにおこないます。システムやプログラムはシンプルな構造をしていません。さまざまな機能が関連しあって1つのシステムあるいはプログラムを構成しています。
そのため、どこか一箇所に変更をくわえると、それまで隠れていたバグが見つかったり、プログラムがうまく作動しなくなったりします。
また、新たなバグが発生した影響で連鎖的に各々の機能がかみ合わなくなってしまうケースもあります。
こうした懸念は、システムやプログラムの全体像が巨大になればなるほど発生するリスクが高まります。大きなプログラムになると、たとえ開発者であっても全貌をすべて把握することは難しく、修正した部分がほかの部分に大きな影響を与えてしまうことも珍しくありません。
こうした不具合を解消するため、システムやプログラムは修正した後には、必ずリグレッションテストを実施します。
リグレッションテストとデグレーション
デグレード(Degrade)は、退化や悪化という意味です。システムやプログラムの不具合を修正した時、ほかに新たな不具合やバグが発生してしまう状態をデグレーションといいます。- ソフトウェアのバージョンアップによって、機能低下を招いた
- 不具合修正をしたのに、別の不具合が発生した/バグが再発した
デグレッションを検証するという意味において、リグレッションテストを「回帰検証」や「ノンデグレードテスト」ということもあります。
リグレッションテストの範囲を決めるポイント
リグレッションテストを効果的に実施するためには、適切な実施範囲とタイミングを見極める必要があります。リグレッションテストの範囲は、主に次の3つのポイントを考慮して決定されます。
リグレッションテスト範囲の決定ポイント1. 影響範囲の把握
範囲を区切ることなく、すべてのテストを初めからおこなうことをフルリグレッションテストといいますが、これがすべてのシステムやプログラムにおいて効率的というわけではありません。開発をスムーズに進めていくためには、リグレッションテストをおこなう一定の条件を設定し、範囲を絞り込む必要があります。 バグの影響する箇所と、それが関係するデータを扱う箇所にテスト範囲を限定することで、リグレッションテストの工数を減らし、効率よく開発を進めることができます。
そのため、影響範囲を正しく把握することが、リグレッションテスト範囲を決定する上で重要になってきます。
リグレッションテスト範囲の決定ポイント2. 部分別リスクレベルの把握
リグレッションテストの範囲決定において重要なポイント2つめは、デグレードが発生した場合のリスクレベルを、部分ごとに把握しておくことです。リスクが大きいと思われる箇所から、優先的にテストを実施していきます。
たとえば、不具合やバグが一部の機能やモジュールで限定的に関わっているのであれば、デグレードのリスクはそれほど高くないといえます。
一方で、システムやプログラムの基盤に深く関わってくるような箇所に関わるものであれば、そのリスクレベルは非常に高いといえるでしょう。
万が一不具合が生じた場合に、どの程度のリスクがあるのかをしっかりと把握しておくことで、適切にリグレッションテスト範囲を決めることができます。
リグレッションテスト範囲の決定ポイント3. テスト項目の優先度チェック
リグレッションテスト範囲を決定する上で重要なポイントの3つめは、過去のデータに基づいた優先度チェックです。 もしも影響範囲が大きくまた広範囲に高リスクであり、なおかつ納期までのスケジュールがタイトであるという場合、すべてに対してリグレッションテストを実施するのは難しいかもしれません。その場合は、過去のデータを利用して不具合発生傾向を精査し、テストを実施するための優先度を定めます。上記のような場合、本来はテスト範囲を絞らずに降るリグレッションテストを実施するのが最善策ではありますが、現実問題として不可能な状況はあるでしょう。そのような局面ではすべてをテストなしに放棄してしまうのではなく、優先度の高い項目、範囲からテストをしていくことが必要です。
リグレッションテストの実施タイミングとは
リグレッションテストは、開発はテストが終了して不具合を修正した後に実施されます。 ゆえに非常に重要な工程でありながら、かけられる工数が少ないということに留意しなければなりません。開発におけるテストは、一般的に次のような順序でおこなわれます。
- プログラムの部分ごとにおこなう単体テスト
- 複数の部分を連結させておこなう連結テスト
- 統合テスト
- 運用テスト
リグレッションテストをおこなわないリスク
リグレッションは、かけられる工数と予算の少なさから、省略されてしまうケースもあります。しかし、リグレッションテストをおこなわないまま納品してしまうと、次のようなリスクが想定されます。リグレッションテストをおこなわないリスク1. 信頼関係の崩壊
リグレッションテストをおこなわないと、デグレーションを残した状態で納品したことになります。そのため、ある時期まで使えていた機能が機能低下を起こし、突然使えなくなるという事態が発生する可能性があります。
また、顧客が運用していく過程で不具合が次々に発生する可能性もあります。
このような場合、顧客との信頼関係は崩れ去るでしょう。
リグレッションテストをおこなわないリスク2. 業務停止
デグレーションを残している状態でシステムやプログラムを使うと、突然の不具合によって業務を停止せざるを得ない状況に陥ることもあります。システムやプログラムが作動しないと仕事が滞るので、企業全体に大きな影響が出てしまいます。
リグレッションテストはツールで自動化できる:そのメリットと適性
システム開発において重要なリグレッションテストは、ツールで自動化することによって工数とコストを削減できます。 また、継続的にテストを実施するために不具合を発見しやすく、不具合やトラブルがさまざまな部分に影響を及ぼしあって修正が難しくなる前に対処できるというメリットもあります。ちなみに、自動化ツールはある程度システム開発を進めた段階のみした導入することができません。開発の初期段階からリグレッションテストをすべて自動化できるわけではないので、注意しましょう。
自動化に向いているリグレッションテスト
自動化に向いているリグレッションテストは、単体テストやバリエーションテスト、バグ修正ごとにおこなうテスト、保守テストなどです。単体テストは、1つの機能やビルド単位でおこなわれますが、このテストを自動化することでバグの多くを削減することが期待できます。
バリエーションテストは、異なる種類のデータを複数入力し、そのデータごとに結果をチェックしていくテストです。 バリエーションテストや、バグ修正ごとにおこなわれるテストのように、何度も実施しなければならないテストは自動化に適しています。
また、システムを修正した時に全体の動きに変化がないかどうかを確かめる保守テストも、システム作成後や修正後にその都度おこなう必要があるテストのため、自動化に向いています。
一方で、自動化ツールの選定やメンテナンス、テストの自動化そのものに工数とコストがかかることも考慮しておかなければなりません。 自動化するコストや工数と、リグレッションテストを自動化せずおこなう場合のコストと工数。それらを比較して置く必要があるでしょう。
ちなみに3〜5回程度おこなう必要性のあるテストは、自動化した方がコストがかからないというのが一般的な指標のひとつです。
リグレッションテスト自動化ツール
自動化は、それ自体が工数とコストを必要とするものです。また、自動化に適したテストとそうではないテストがあり、何でも自動化すれば良いというわけではありません。ここに挙げた代表的なリグレッションテスト自動化ツールは、あくまで参考です。設計する際には、システム開発にもっとも適したリグレッションテストについても、事前によく計画しておく必要があるでしょう。
初心者から上級者まで利用可能な「Selenium」
Seleniumuは、Webアプリのテスト自動化をするためのツールです。Firefoxのアドオンである「Seleniumu IDE」を活用することによって、
Firefox上のユーザーがおこなったアクションをスクリプトにすることができるなど、プログラミング言語に詳しくないビギナーにも使いやすい点が特徴です。
「Selenium WebDriver」は、Java、C#、Python、Rubyなど多言語のスクリプト作成に対応しています。
継続的に自動テストを実行「Jenkins」
Jenkinsは、Webアプリの開発におけるテストを自動化できます。スケジューラー機能が搭載されているため、定期的なテスト実行を指示することも可能。ほかのツールと比較すると、トラブルが発生した際の対処法を見つけやすいという特徴があります。
ただし、Jenkinsの機能はあくまで実行命令のスケジューリングであるため、実際にテストを実行するには、プラグインを紐づける必要があります。
プログラムを動作させることなくソースコードからエラーを発見する「静的解析ツール」や、単体モジュールをテストするための「ユニットテストツール」といったプラグインを組み合わせることで活用できます。
1つのスクリプトがiOSとAndroidに対応「Appium」
スマホアプリのテスト自動化に便利なツールとして知られるのが、オープンソースのテスト自動化フレームワークAppiumです。1つのテストスクリプトで、iOSとAnadroidそれぞれに対応するという特徴があり、元のアプリのソースに手を加えることなくテストを実行できるというメリットを備えています。
負荷テストをおこなう「Apache Jmeter」
負荷テストとは、システムにわざと擬似的な大量アクセスをおこなってシステムがそれに耐えられるかどうかを試すテストです。Apache Jmeterは、パフォーマンスの測定、HTTPレスポンスの妥当性をチェックすることができるため、機能テストを実施することもできます。
テスト結果はグラフで表示させたり、メールでデータを送信したりできます。
まとめ
リグレッションテストは、納期がタイトであったりコスト削減を迫られたりする場合に、カットされやすい工程です。しかし、システムやプログラムを正常に運用するためには必須。リグレッションテストをおこなわずにクライアントに成果物を納めた場合、不具合やバグが生じて顧客との信頼関係を損なってしまうおそれもあります。開発の当初からしっかりと計画を立てて、効率的にテストをおこなえるようにしていくことが肝要です。