システムの開発中には、修正などによってさまざまな問題が生じます。把握が難しい複雑なシステムに生じた問題を把握できるのがレグレッションテストです。本記事では、レグレッションテストの意味から、実施するメリット、実行する際のポイントを解説します。
レグレッションテスト（リグレッションテスト）とは
レグレッションテストとは、コードを修正した場合などに別の場所まで影響が及んでいないかを把握するためのテストです。レグレッションテストにはどのような意味があるのか、また、デグレーションとの違いについて以下で解説します。
レグレッションテストの意味
レグレッションテスト（Regression Test）のレグレッションには日本語の「回帰」「後戻り」などの意味があり、「回帰テスト」「退行テスト」とも呼ばれます。レグレッションテストは、主にバグの修正、システム開発でコード変更などがおこなわれた場合に実施し、どこにも影響が及んでいないかを調べます。
システムはさまざまな機能が組み合わさっているため、一部を変えただけでも、関係している別の部分に影響が及ぶケースもあり、注意が必要です。変更が生じた場合には、このレグレッションテストをおこなってほかの箇所にエラーなどが起きていないかどうかを調べられます。大規模なものほど行った修正がどの機能に関係しているかがわかりにくくなるため、影響している箇所を見つけるレグレッションテストの実施は欠かせません。
デグレーションとの違い
デグレーションはレグレッションテストと一緒に用いられることが多い言葉です。「デグレード（Degrade）」は「退化」「低下」など、「レグレッション」に近い意味を持ちます。デグレーションは、システム開発中に一部だけ修正することなどで変更が起きた場合に、それまでは正常だったシステムの動作にまで影響が及んで機能性やパフォーマンス性が低下してしまうことを意味します。
修正によってほかの機能まで修正の影響を受けてしまった場合や、インフラ環境に適用しない形式に変わって使えなくなってしまった場合など、別の部分に思いがけない悪影響を及ぼすことがデグレーションなのです。デグレーションが発生しているかもしれない場合には、レグレッションテストを実施して調べられます。
レグレッションテストをおこなう理由
システムにはさまざまな機能を搭載するため、複数のコードやシステムが複雑に関係して構成されています。コードを一部分だけ直したり変えたりする場合でも、そこに関係する場所が修正された場所の影響を受けて突然動作しなくなるなどの問題が起きるため、エラーなどが起きていないか調べなければなりません。
規模の大きなシステムなどでコードが複雑化している場合には、開発者本人でも変更があった部分に関係する場所すべての把握は難しいといった問題があります。修正した場所に影響を受けている部分は、レグレッションテストで調べられます。レグレッションテストを実施するとコード変更などの理由で悪影響を受けている問題のある場所が見つかります。状況に応じて範囲を絞ったり、目的を絞って単体のテストをおこなったりして隠れている問題を発見し無理なく検収すると、安定したシステムを完成させられます。
レグレッションテストをしないことで起こる問題
システムの開発中、コードの変更や修正といった作業は何度もおこなわれます。修正作業の後にはデグレーションによって機能や品質が落ちるケースがあるかもしれません。そのため、問題が起きているかを見るためにレグレッションテストがおこなわれます。ですが、なかには納期や予算などの理由から実行できない場合があるかもしれません。
もしレグレッションテストをしない場合には、デグレーションに気づかずそのまま納品してしまうおそれがあります。画面が開かない、エラーが起きてシステムが使えないなどの大きな問題に気づかずにシステムを納品すると、問題が頻発することにより自社製品の信頼が失われてしまいます。デグレーションが生じるとシステムの再改修をしなければならなくなるため、再改修に多くのコストがかかる点も問題です。早い段階でバグを見つけないと修正する工程が増加するため、必要な段階でレグレッションテストをおこなうことが大切です。
レグレッションテストをおこなう範囲
レグレッションテストには、範囲を絞らずすべてのテストをやり直すフルレグレッションテストと、調べる範囲を決めておこなうテストがあります。フルレグレッションテストは、システム上に生じているエラーや問題をすべて発見できますが、多くの時間と工数がかかります。開発をスムーズに進めるためには、レグレッションテストの調べる範囲を絞り込んで、効率よくおこなうことが大切です。範囲を絞り込む場合、バグの修正場所に影響を受ける範囲を把握して、その場所だけをテストするケースや、事前に設定していたリスクレベルに応じて範囲を設定するケースなどがあります。修正後には、修正した場所の影響を受ける範囲だけを限定してテストをおこないます。また、さまざまな機能に関係しているシステムの基盤部分など、リスクレベルの高い部分で問題が生じていると重大なリスクにつながるため、リスクレベルが高く設定された場所は優先してテストをおこなわなければなりません。
レグレッションテストに適したタイミング
レグレッションテストは、単体テスト、連結テスト、結合テスト、システムテストといった順序で、単純なテストから徐々に複雑で大きなテストに変えていきます。テストに適したタイミングは、主に「エラーの修正後に確認するタイミング」ですが、開発プロセスによってテストの実施に適したタイミングはさまざまです。
アジャイル開発などでスプリントやイテレーションといった短期間の開発工程を繰り返す場合は、「個々のスプリントやイテレーションを終えたタイミング」がレグレッションテスト実施に最適です。連続的な開発プロセスが特徴のウォーターフォールモデルやV字モデルなどでは、要求分析や要件定義、基本設計、詳細設計など、各開発プロセスに適した範囲・内容のテストをおこないます。レグレッションテストは、各テスト工程完了後が実施に適したタイミングです。さらに「ほとんどのバグ、修正見送りなどがクローズして不具合曲線がほぼ終息した時点」もこれらのモデルでレグレッションテストするべきタイミングです。
レグレッションテストをおこなう際のポイント
レグレッションテストは開発の際に重要な役割を担うテストですが、実際には多くの工数とコストをかけられないケースがあるかもしれません。フルレグレッションテストには工数とコストがかかりすぎることから、大きな問題があるケースでなければ実施が難しいといった問題があります。このため、レグレッションテストは重要な機能に関係する場所を中心にして範囲を絞ると効率よく実施できます。
納期までに時間の余裕がない場合には、過去にバグが生じていた場所を調べて、過去の傾向から問題が生じやすい場所の優先度を決めておこなう方法もあります。レグレッションテストは何度も実行すること、実施範囲を広げていくことが重要です。納品前にレグレッションテストをおこなうのはもちろんですが、単体テストからシステムテストまで、段階的に実施されるすべてのレベルで実行する必要があります。
レグレッションテストの自動化やツールもおすすめ
レグレッションテストは同じテストを何度もおこなうため、コスト削減が期待できる自動化・ツールの利用がおすすめです。同じプロセスを繰り返す業務の場合は人が手動でおこなうのではなく、ツールなどによる自動化を取り入れると、コストや工数が削減できます。自動化する場合には、ツール作成や保守などのコスト・工数と、手動時の工数を比較して検討すると、効率よくコストを抑えられます。自動化により、これまでテストをおこなっていた人手が不要になって人的リソースが確保できる、こまめにチェックできるため早期にバグを発見できるなどのメリットも得られます。
レグレッションテストの自動化は、開発手法にもよりますが何度も実施する単体テストや保守テストなどで取り入れると工数が効果的に削減できます。さまざまなデータを登録してから問題が生じている場所を調べるバリエーションテストのように、手間や時間がかかるテストも自動化がおすすめです。
まとめ
レグレッションテストは、システム開発中に生じる不具合の検出に必要なテストです。
ソフトウェア開発の品質を上げるためにはOBPM Neoなどのプロジェクト管理ツールの導入もおすすめです。
