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