今回は、「リグレッションテスト（回帰テスト）」についてご紹介します。まずは、リグレッションテストの概要・デグレーションとの違いを説明し、「実施のタイミング・範囲/実施しないリスク・テスト自動化」について一挙に解説。「リグレッションテストの意味や重要性を知りたい」という方や、テスト初心者の方必見のお役立ち情報をお届けします。
リグレッションテストとは
まず、リグレッションの意味としては、
「開発工程の段階で検出された不具合・バグを修正した際に、それまで正常に動作していた部分が異常をきたす」などの現象を指します。
また、リグレッションテスト【regression testing】とは、前述のように開発したプログラムの一部を変更・修正後のタイミングで、予期せぬリグレッションが発生していないかを確認する検証方法を指します。別称「回帰テスト/退行テスト」とも呼ばれています。
つまりは不具合修正だけではなく、プログラムのどこかに変更・修正を加えた際には、リグレッションテストを実行し、プログラム全体を通して影響がないかをチェックすることが大切です。
デグレーションとの違い
つぎに、リグレッションテストと同時に用いられることの多い、
「デグレーション」についてご紹介します。
両者の大きな違いは「用語が使用される状況」です。
デグレーション【 degradation】とは、
プログラムの不具合修正・機能追加といった一部の変更・修正に伴い、それまで正常だった処理や操作に問題が発生し品質が落ちてしまうことです。
単語の意味としては「リグレッション」と同一の「回帰・退行」を指しますが、デグレードとは主に「品質が落ちて劣化した状態」を表します。
つまり、開発・検証の現場においては、リグレッションテストがデグレードを検証するという観点から「ノンデグレ－ションテスト」「デグレートテスト」と呼ばれることも多々あります。
リグレッションテストの目的
リグレッションテストを行う目的は、
「プログラムの一部変更・修正が、既にテスト済みの箇所に影響を及ぼし、不具合・バグを発生していないかを確認すること」です。
システム・プログラムの構造は、各機能が複雑に絡み合っています。
そのため、プログラムの一部を変更・修正した際には、残存した別の不具合が検出されるケースや、正常であったはずの機能に異常をきたすリスクなどが付きまといます。
また、これらの現象（デグレード）はシステムやプロジェクトの規模感によって、影響の大小が異なります。
デグレードの発生は、作業工程の遅延・修正コストの増大・品質低下に繋がります。
このようなトラブルを未然に防止するためにも、リグレッションテストの実施は非常に重要であると言えます。
リグレッションテストのタイミングと範囲について
つぎは、「リグレッションテストのタイミングと範囲」について解説します。
リグレッションテストは一般的に、「開発後・各テスト工程後」に実施されます。
しかし、多くの開発・テスト工程のスケジュールにおいて、リグレッションテストにかける時間はあまりないというのが現実です。
リグレッションテストは他のテスト手法に比べ、実施工数のかかる対応のテストです。
だからといって、リグレッションテストを省略した場合、基本機能を損なう品質低下・不具合残存、リリース後の信用失墜などのトラブルに繋がります。
そのため、上記を考慮した上で、実施範囲に一定の基準を設け事前に絞り込み・効率化を図る必要があります。
タイミング
リグレッションテストを行うタイミングは、以下の「各テスト工程後の実施」が一般的です。
テスト工程は段階を踏むごとに、検証内容が複雑になっていきます。
そのため、リグレッションテストは、以下全てのテストにおいて初期段階で導入すべき観点です。
- 単体テスト
- 連結テスト
- 統合テスト
- 運用テスト
具体的には上記のテスト工程を行うたびに、不具合を検出したら修正を行い、再度同様のテストを行って不具合がないかを検証します。
また、リグレッションテストで検知される不具合の影響度の大小は各テスト工程で異なりますが、不具合の早期発見・修正に繋がる体制を整備しておきましょう。
範囲
つぎは、「リグレッションテストを行う範囲」について説明します。
フルリグレッションテストとは、事前にテスト範囲を絞り込まず、全てのテストを最初からやり直す方法です。
しかし、前述でも言及の通り、リグレッションテストにかけられる時間があまりないことを考慮すると、フルリグレッションテストの実施は賢明ではないかもしれません。
できる限り少ない工数で、効率的かつ効果的なリグレッションテストを実現するためには、
テスト範囲を事前に絞る方法が役立ちます。
テストをフルで行わない場合に範囲を絞るポイントは、以下の通りです。
- 不具合修正が影響する箇所と、関係データを扱う箇所のみにテスト範囲を絞り込む
- 事前にリグレッションテストにレベルを設け、テスト本番では定義されたレベルのテストのみを実施
その他、「開発担当者へのテスト情報共有」や「開発時に設定したテストシナリオを基に、全体の処理が正常か確認する」などの方法も挙げられます。
リグレッションテストを実施しないリスク
リグレッションテストを省略した場合、製品・サービスを納品した場合、
「デグレーション残存の可能性があるもの」を納品・リリースしたことになります。
そのため、万が一不具合・バグの残存や新たな障害発生による業務停止などの
悪影響や損害など、様々なトラブルを招くリスクが増大します。
結果としてこれらのトラブルによる企業ブランドの低下・信用失墜にも繋がりかねません。
以上の事から、ソフトウェア開発においてリグレッションテストは
「必要不可欠な作業工程」であると言えます。
今回ご紹介した、リグレッションテストも同じ工程を何度も繰り返すという特徴から、
ツールで、ソフトウェアテストにまつわる作業の全体か、一部の作業工程を自動化できる
テスト自動化が可能です。
自動化の主なメリット・ベネフィットは以下の通りです。
自動化の主なメリット・ベネフィット
- テスト実行時間の削減
- テストデータの安定性・正確性向上
- システム及び人的資源の利用改善
- テストケース管理コストの削減
- テストデータストレージの保守、改善 など
また、自動化に適したテストの種類・特徴は以下の通りです。
| テストの種類 | 特徴 |
|---|---|
| 単体テスト | 機械やビルド単位で行うため工数が多い |
| バリエーションテスト | 手作業での実施に時間がかかる |
| 保守テスト | テスト範囲が広く、システムの作成・修正ごとに実施する |
上記の表から、自動化に適したテストケースとしては
- 同じ作業工程が繰り返し実行される
- ミス・不備が発生しやすい
- 変更が少なく安定性がある
といったタイプが挙げられます。
自動化を導入する際の注意点としては、
- ツール購入などにかかる導入コスト
- テストの工数削減
以上の２つを考慮することが挙げられます。
つまり、対象のシステム・ソフトウェアにおいて、
- 本当に自動化すべきテスト業務なのか？の見極め
- どの手法が効率的且つ有効なのか？ など
について、慎重かつ適切に検討することが重要です。
まとめ
いかがでしたでしょうか？
今回は、ソフトウェアテストにおける「リグレッションテスト」に注目し、デグレーションとの違いや、テストの概要、重要性や自動化などについて解説しました。
本記事を通して「実施しないことによるリスク」を把握した上で、リグレッションテストの重要性もご理解いただけていれば幸いです。
リグレッションテストは工数のかかるテストではありますが、製品・サービスの品質・安全性を保つ上で非常に重要なテスト工程です。
今回ご紹介した内容をおさえ、リグレッションテスト及びデグレーションについて正しく理解し、自動化導入も検討しつつ、網羅的なテスト実現に役立てていただければ幸いです。
最後までお読みいただきありがとうございました。
