システムの開発が進み、その複雑さが増してくると、改修した部分が影響して不具合が発生するリスクが高くなります。
そのため、改修内容に応じてその影響を確認する「リグレッションテスト」を実行して、不具合を早期に検出することが重要です。
今回はテスト工程におけるリグレッションテストについて、定義や目的、効果的な実行タイミング、そしてリグレッションテストの自動化について解説します。
- もくじ
1.リグレッションテスト(回帰テスト)とは
「リグレッションテスト(Regression Test)」とは、プログラムの一部を変更・修正した後で、変更箇所および関連する箇所が正しく動作するか、システムに予想外の影響が現れていないかを確認するテストのことを指します。
リグレッションには「回帰」「退行」という意味があるため、「回帰テスト」、「退行テスト」とも呼ばれます。
1-1 リグレッションテストの目的
リグレッションテストの目的は、プログラムの変更・改修が既に検証済みの部分に悪影響を及ぼして、新たに不具合を引き起こしていないかを確認することです。
改修箇所が全く新しいモジュールやメソッドであれば、影響は比較的少ないと予想されますが、既存のモジュールやメソッド、あるいは基盤となるコードを変更する場合、その既存コードを利用する機能全体に影響を及ぼすリスクが発生します。
また、影響範囲が広かったり、システムの性質上、クライアントの業務に密接に関わっていたりする場合、わずかな修正が深刻な事態を招く可能性があります。
このため、プログラムの変更や修正を行う際、改修前に正常に動作していた処理や操作が、改修後も同じようにできることを確認することを目的に、リグレッションテストを実施します。
1-2 リグレッションテストとデグレーションの違い
「リグレッションテスト」のときに、よく出てくる単語が「デグレード(degrade)」です。現場では「デグレ」と略されることもあります。「デグレーション」はこの名詞形で、「悪化」「退化」という意味です。
これはプログラムの変更によって、機能が劣化する、パフォーマンスが悪化する、改善されたバグが復活するという、悪い影響が出ている"状態"を指します。
実は、リグレッションもデグレーションも、単語の意味合いとしてはほぼ同じなのですが、慣用的に、"テストの名称"としては「リグレッションテスト」、悪化した"状態"を表すときは「デグレード(デグレーション)」と、使い分けられています。
2.リグレッションテストを行わないリスク
リグレッションテストを省略してしまうと、システム納品後に「画面が開かない」「処理が終わらない」といったような、基本機能を損なう重大な欠陥が発見されるリスクがあります。
これではせっかく時間とコストをかけてシステム開発をしても、顧客に多大な損失を被らせ、引いては信頼を大きく失墜させてしまうことになってしまいます。
リグレッションテストの実行には工数がかかりますが、デグレード(デグレーション)の有無を調べるテストでもあるため重要です。欠陥を見落とさないためにも省略せずに行いましょう。
3.リグレッションテストの実行範囲とタイミング
効率良くリグレッションテストを実行するためには、リグレッションテストの実行範囲と実行タイミングを見極めることが重要になってきます。
この章で詳しく解説していきます。
3-1 リグレッションテストの実行範囲
リグレッションテストの実施範囲は、以下3つのポイントに沿って決めていきます。
- 変更を加えるプログラムの影響範囲を的確に把握すること
- デグレードが発生した時のリスクが高い箇所を優先的に検証すること
- 過去のデータや傾向からテスト項目の優先度を判断すること
デグレードが発生する確率は、変更対象のプログラムがシステム内でどのくらいの影響を及ぼすかによって変わります。例えば、限定された機能・モジュールにのみ関わる変更であればデグレードのリスクは小さくなり、各機能の基盤となるようなソースコードに対する変更であればリスクは大きくなります。
対象のプログラムがシステム内でどのような位置付けにあるのか、変更を加える前にしっかりと調査しておくと良いでしょう。
綿密な調査による影響範囲の把握と併せて、万一不具合が発生した場合にリスクが高いのはどの機能かを確認しておくことも大切です。その機能を利用する想定業務フローに沿ったテストを数パターン実行することで、影響範囲調査のミスを軽減できるでしょう。
しかし、このような過程でテスト項目が増大し、定められた納期までにテストを全て実行することが難しい場合は、過去の不具合発生傾向に基づいて、実行するか否か、優先度をつけます。
リグレッションテストの実行範囲を絞り込まずに、全てをテストする「フルリグレッションテスト」を実行する方法もありますが、限られたリソースの中で最も確度の高い方法でテストして効果を最大化することが、現実的な対策となります。
3-2 リグレッションテストの実行タイミング
テスト工程は単体テスト、結合テスト、システムテストという順序で、単純なテストからより複雑なテストへと進んでいきます。
リグレッションテストは、この全てのテスト工程で実行するのが望ましいです。
リグレッションテストによって検知される不具合の影響度はさまざまですが、リグレッションテストの観点をテスト工程の初期段階で導入し、不具合を早期に検知・修正できるような体制づくりが求められます。
4.リグレッションテストの自動化とは
テストの自動化とは、テストの手動プロセスを、ツールなどを使って人が介在せずに機械的に実施できるようにすることです。これによってテスト実行時の工数やコストを削減することができます。
同じ手順のテスト実行を何度も行うリグレッションテストは、コストパフォーマンスが高いため、自動化に向いていると言えます。
リグレッションテストが発生することが想定される部分については、テスト自動化の導入がカギとなります。特に一つの機能やビルド単位で行う「単体テスト」は、細かい単位でのテスト実行を繰り返すことが多く、リグレッションテストの実行も多くなるため自動化に向いています。
また、多種多様なデータを入力して不具合がないかチェックする「バリエーションテスト」 についても手動での実行に手間がかかるため、リグレッションテストが想定される個所については自動化が望ましいでしょう。
システム修正後、全体の挙動に不具合がないかを確認する「保守テスト」も、ローンチ後に行われるリグレッションテストの一種です。
システムの作成や修正のたびに実行する必要があるので、可能であれば自動化しておくことで工数の節約になります。
リグレッションテストの自動化を検討する場合は、ツールの購入やテストプログラムの作成などの導入時にかかるコストの増加分およびプログラム修正に伴うメンテナンス工数とテスト実行時の工数削減の両方を考慮して判断していくと良いでしょう。
まとめ
リグレッションテストとは、プログラムの一部分を変更・修正したことで、システムに予想外の影響が現れていないかを確認するテストです。
思わぬ動作不良や不具合を発生させてしまうリスクを回避することを目的としています。
システム改修に伴う影響範囲が広く、工数や納期の関係から全範囲に対してリグレッションテストを行うことが困難な場合は、以下のポイントをおさえて実行しましょう。
- 変更を加えるプログラムの影響範囲を的確に把握する
- デグレードが発生した時のリスクが高い箇所を優先的に検証する
- 過去のデータや傾向からテスト項目の優先度を判断する
リグレッションテストは、顧客の信頼を失わないためにも、各テスト工程に組み込んでいくことが重要です。重大な欠陥を見逃さないように実行していきましょう。