「レグレッションテストとは…？」
「聞いたことあるけど、詳細は知らない…」
「レグレッションテストは外注化できないのか…」
などレグレッションテストについてお悩みの方も多いでしょう。この記事ではレグレッションテストについて解説します。
レグレッションテストは、これまで行ってきた開発の影響により、他のシステムが動かなくなってしまったり、不具合が発生してしまったりしていないかを確認するテストです。
今まで正常に動作していたシステムに不具合が発生してしまうと、クライアントの信頼を失ってしまったり、ビジネス的な機会損失を受けてしまったりと、レグレッションテストを軽視するとリスクになるのです。
とはいえ、レグレッションテストは難しく、テストする範囲を決めたり、詳細なテスト項目を決めたりと、何も知らない状態では進みません。
ここからはレグレッションテストの目的、方法を具体的に説明し、外注化するメリットについても挙げていきます。この記事で「レグレッションテスト」について詳しくなり、システムに不具合が起きないよう対策しましょう。
レグレッションテストとは
レグレッションテストとは、別名「退行テスト」とも呼ばれており、新しく開発されたシステムで変更が発生した箇所によって他の機能に影響が及んでいないかを確認するテストを指します。
システムに変更を加えたり、機能を追加したりすると、別の既存機能が動かなくなるなど、それにより負の影響を受けることがあります。システムの変更や追加を行った後でも、今まで正しく動作していた機能が正常に動くか確認するのです。もし、動かなかったり、正常に動いていなかったりする場合は修正します。
変更があった箇所のテストを行うのであれば、テストする箇所は明確ですが、修正がない箇所のテストとなると、影響がどこまで及ぶのかを調べるのは大変な作業です。
無駄に影響がない範囲までテストしないように範囲を過不足なくテストすることが重要になってきます。
レグレッションテストの目的
レグレッションテストは、変更していない既存システムに不具合が発生していないかを確認することが目的です。
改修箇所が存在せず、新しい機能でどこにも影響が出ない場合は別ですが、そのようなケースは稀で、他の箇所に影響が出る場合がほとんどでしょう。影響範囲が広かったり、クライアントの業務に直接関係するシステムに影響がある場合は、重点的にレグレッションテストを実施する必要があります。
そのため、プログラムの改修後にこれまで通りにシステムが正常に動くかどうか、アウトプットされるものに影響が出ないかどうかをテストし、依頼元に確認をもらう前に不具合を修正する必要があります。
レグレッションテストを行うタイミング
テスト工程は、単体テスト、結合テスト、システムテストと徐々にテストする範囲が広くなることが特徴です。当然、テストする範囲が広くなると不具合が発生する箇所を特定することも難しくなってくるため、単体テスト→レグレッションテスト、結合テスト→レグレッションテストと、全てのテスト工程でレグレッションテストを実施するのです。
とはいえ、全てのテスト段階でレグレッションテストを行うとテストのボリュームが膨大になってしまうため、範囲を限定することも重要になってきます。
デグレーションテストとの違い
「レグレッションテスト」と「デグレーションテスト」の違いはあるのかと疑問を持つかもしれませんが、ほとんど変わりません。
「レグレッションテスト」のレグレッションとは「回帰」という意味です。前の状態に戻ってしまうことを意味します。レグレッションテストは、改修を行うことによって改修前の状態に回帰してしまうこと、つまり元の状態に戻ってしまっていないかをテストしています。
対して、「デグレーション」のデグレードとは「劣化」という意味です。改修前よりも品質が落ちてしまうことを意味します。テグレーションテストの意味合いとしては改修前よりも性能が悪くなっていないかをテストしています。
レグレッションテストとその他のテストとの違い
コンポーネントテスト
コンポーネントテストとは、別名「単体テスト」と呼ばれており、テスト工程の最初に行われるテストとなります。コンポーネントテストの目的は、モジュール単体で正しく動作するか、想定通りのエラーが発生するかどうかを確認することです。
大きくは正常系、異常系のテストに分かれており、正しい値が入力された場合は予想した結果が返されるかどうか、正しくない値が入力された場合でも、予想した結果が返されるかどうかを確認します。この時点で発覚したバグや不具合は、修正し次の開発工程へ進みます。
結合テスト
結合テストはモジュールを組み合わせて動作させたときに、正しく動作するのかをテストします。モジュール間でやりとりするデータの整合性すなわち、モジュール間インターフェースの整合性について詳細にチェックします。
基本的に上位モジュールから順にテストを行い、動作に問題がないかどうかを確認します。
システムテスト
システムテストとはシステムが設計仕様を満たしているかどうかをテストします。外部設計、内部設計工程の誤りの発見を行います。
システムテストでは主に以下のテストが行われます。
・機能テスト
仕様で定められた機能がすべて備わっているかどうかをテストします。
・性能テスト
仕様で定められた性能（レスポンスタイム、スループット）が出るかテストします。
・負荷テスト
負荷をかけた場合でも正しくテストできているかをテストします。
受け入れテスト
受け入れテストとは、開発されたソフトウェアなどのシステムが、発注者の要求通りに動作するか確認するためのテストを指します。
基本的に発注者側が実際にテストを行い、疑問点や不具合があればシステムを開発した受注者側に問い合わせる流れです。
実際に運用する前の最後のテストとして受け入れテストは行われ、ここで不具合や疑問点などをすべて洗い出しておくことが目的です。
※関連記事
受け入れテストとは？言葉の定義や目的、実施方法を徹底解説
レグレッションテストを実施しないことのリスク
レグレッションテストの概要について説明してきましたが、実際にテストを行わないとどのようなリスクが発生するのでしょうか。システムの信頼性と工数の観点から具体的に解説していきます。
デグレが発生するとシステムの信頼性がなくなる
先述の通り、デグレが発生するとシステムの信頼性が失われクライアントやユーザーの満足度が低下するリスクがあります。
システムが大規模または、複雑化していくと不具合が発生する可能性が高くなります。そのためシステムの改修を行い変更箇所のみのテストを完璧に行なったとしても、他のシステムも正常に動作するかの保証はどこにもないのです。
-
- 改修を行なったことでこれまで正常に動作していたシステムにバグが発生した
- 正常にアウトプットしてきたデータに不具合が発生し、クライアントに多大な損害を与えた
上記のような事象が起こってしまっては、これまで気づき上げてきた信頼が失われ、ビジネスチャンスを失うことになりかねません。
レグレッションテストは手間ではありますが、クライアントからの信頼を失うことを考えれば、時間と費用をかけて実施する価値があると言えるでしょう。
より多くの工数がかかる
レグレッションテストの実施には当然、工数が発生します。しかし、レグレッションテストを行わずにテスト工程を進めていった場合、不具合の発見が遅くなり、バグ発生箇所の特定が難しくなり、結果的に大規模な調査を行わざるを得ない状況になってしまいます。
システムが稼働する前のクライアントの環境で不具合を確認した場合なら、まだ問題は小さくて済みます。しかし、稼働した後のクライアントの環境で不具合が発生してしまえば、クライアントに損失を与えてしまい、損害賠償等を要求される可能性すらあります。
多少工数がかかったとしても、レグレッションテストを実施し最終的な工数を最小限に抑えることが重要になってくるでしょう。
レグレッションテストで注視するポイント
重要度が高いものからテストを実施する
他のテストと同様、テストする範囲を増やしていけば当然工数も増えますし、コストも増えていきます。基本的な操作をこれまで通り行うことができるか、改修箇所と密接に関わっている機能が正常に動作するかどうかを重点的にテストしていきましょう。
テスト範囲を限定せずにすべての箇所をテストする手法もあります。システムの規模やプロジェクトのメンバーの数にもよりますが、できる限り影響があると判断した箇所のテストは実施した方がよいでしょう。
システムの規模が大きかったり、プロジェクトメンバーが少なかったりする場合は、予めテストする優先順位を決め、実施していくことが大切です。
不具合が収束したタイミングでテストを実施する
通常テストを行う際は、単体テスト、結合テスト、システムテスト、受け入れテストと順に進めますが、改修したすぐのテストは不具合が発生しやすくなっています。
そのため、不具合が多く発生している状態でレグレッションテストを実施しても、二度手間となってしまう可能性があります。まだ改修箇所の調査や単体テストなどで発覚した不具合の改修が完了していないため、それを改修した後にもレグレッションテストが必要になるからです。
レグレッションテスト以外のテストが完了し、不具合が発生しなくなったタイミングでレグレッションテストを行うのが良いでしょう。
各テストレベルでレグレッションテストを実施する
レグレッションテストの実施は一回ではなく、単体テスト、結合テスト、システムテストの各テスト工程でバグが収束したタイミングで行いましょう。
仮にレグレッションテストを1度きり（最終的に行う形）の実施とする場合、不具合が発生したときに調査範囲が膨大になってしまい、作業工数が増加してしまうためです。
各テスト工程にて不具合が出なくなったタイミングでレグレッションテストを行うのが、最小工数でシステムの改修を終えることができるでしょう。
工数削減のためにテストの自動化を検討する
レグレッションテストは各テスト工程ごとに行わなければならない性質上、一回でテストが済むわけではなく、繰り返しテストすることが要求されます。
そのため、早い段階でレグレッションテストを自動化することができれば、後のテスト工数を削減することができます。予めレグレッションテストを自動化することを考え実施することもポイントです。
影響が出るシステムを洗い出す
レグレッションテストは改修が行われていない箇所のテストを行うため、テストを行う箇所を限定しなければ大きな工数がかかってしまいます。
また、全く影響がない範囲のテストを行なっても工数の無駄遣いです。あらかじめ改修により影響が出るシステムを洗い出し、そこを重点的にテストしていくことがポイントとなります。
システムに長く携わっている方などの有識者と密に連絡をとり、影響範囲を洗い出すことで結果的にコストを削減することにつながるでしょう。
レグレッションテストは外注化が可能である
単体テスト、結合テスト、システムテスト、受け入れテストなどの工程に比べて軽視されがちなテストですが、レグレッションテストを行わずに既存システムが正常に動かなくなってしまえば、クライアントの信頼を損ねることになりますし、ビジネスチャンスを逃してしまう可能性があります。
確実にテストを遂行し、最終的な工数を削減させるために、レグレッションテストを外注化するという方法を提案します。レグレッションテストに実績がある企業やパートナーを見つけ、効率的にまた、コストを削減しながらテストを進めてください。
まとめ
この記事で説明してきた内容をまとめると以下のとおりです。
-
- レグレッションテストとは改修前とシステムの動作が変わらないことをテストすること
- レグレッションテストを行うタイミング
- レグレッションテストを行う範囲について
- レグレッションテストを外注化するメリット
レグレッションテストは重大なテストであるため、確実に行う必要があります。レグレッションテストを専門的に行なっている企業にテストを外注化すれば、安全確実なテストを実現させることができるでしょう。
株式会社エイチビーラボでは、ベトナムに特化したオフショア開発サービスを提供しております。レグレッションテストには豊富な実績があります。クラウドやITインフラ、システム関連でお困りの方は、ぜひお気軽にお問い合わせください。ご相談から、開発、運用まで親身にサポートいたします。
