回帰テストとは？詳しく解説します

TOP
コラム
回帰テストとは？詳しく解説します

回帰テストの概要

ここでは、回帰テストとは？という点について詳しく解説させていただきます。
回帰テストは、前にテストしたソフトウェアが変更後もまだ動作するかどうか、機能テストと非機能テストを再度実行して確認する作業のことで、あらゆるテスト現場において必要な知識の一つです。回帰テストはほぼすべての組織で実施されていますが、プロジェクトによって独自の手順を行う場合や、特定のツールを利用する場合、一定のルールに従って実行する場合など様々な取り組み方があります。
とはいえ、基本的な知識やアプローチは共通しておりますので、ここではそれらについてまとめて説明させていただきます。また、回帰テストはテスト手法の一つというだけでなくプロジェクト全体の一つとして考える必要があります。それらを正しく理解し、実行するためには、回帰テストは回帰テスト戦略によって行われることが重要です。このようなテスト戦略は、チームが現在の回帰テスト手法のミッシングリンクをより深く掘り下げ改善を行うことにも役立ちます。
以上が簡単ではありますが回帰テストの概要となります。
さらに詳しく解説させていただきますので、参考にしてみてください。

回帰テストとは

回帰テストについて掘り下げて説明させていただきます。
すでに冒頭でも説明したように、回帰テストはコードの改訂、更新、または最適化の後、アプリケーションが意図したとおりに動作し続けることを検証するソフトウェアテストの一種です。
アプリケーションは新しい機能を追加して進化し続けるため、チームは回帰テストを実行して、既存の機能が期待どおりに機能し、新しい機能によってバグが導入されていないことを評価する必要があります。 回帰テストが必要になる可能性のある変更には、バグ修正、ソフトウェアの機能強化、構成変更などがあります。これらのリグレッションをテストするための仕組みは、欠陥が見つかるたびに大きくなる傾向があるため、通常はテストの自動化でカバーされます。テストの自動化やそれらに関する知識は後述させていただきますが、以上が回帰テストに関する基本的な理解についての説明とさせていただきます。

回帰テストが重要視される背景について

次に、回帰テストが重要視される背景について説明させていただきます。
ソフトウェアアプリケーションは、新しい拡張機能 (機能、パフォーマンス、さらにはセキュリティの向上)、既存の機能の微調整または変更、バグ修正、および更新のために直接変更されます。また、インターフェイスを介して機能を提供するために消費するサードパーティサービスによっても間接的に影響を受けます。このようなアプリケーションのソースコードの変更は、計画的であっても意図的でないものであっても、検証が必要となることは言うまでもありません。さらに、アプリケーションが使用する外部サービスへの変更の影響を検証する必要があり、この工程を軽視してしまうと思わぬ問題やトラブルに発展する可能性があります。
そのためチームは、アプリケーションの変更されたコンポーネントが期待どおりに機能し、他のセクションに悪影響を与えていないことを確認するという作業が必要となります。
ソフトウェアが更新または変更されたり、変更されたターゲットで再利用されたりすると、新しい障害の発生や古い障害の再発生など多くのリスクを抱えるため、リビジョン管理が重要となります。

ある領域の問題を修正すると別の領域でソフトウェアのバグが発生することや、一部の機能が再設計されると、元の実装で行われたいくつかの同じ間違いが再設計で行われる場合があります。
そのため、ほとんどのソフトウェア開発の状況では、コーディングのネストプラクティスとして、バグの修正を行った後にはバグを再現させたテストを実行して、さらに、プログラムに以降の変更を行ったときに定期的にプログラムへの同じテストを再実行することが重要となります。これは、プログラミング手法を使用した手動テスト手順で実行できるが、多くの場合、自動テストツールを使用して実行されます。このようなテストスイートには、テスト環境ですべての回帰テストケースを自動的に実行できるようにするソフトウェアツールが含まれます。

各種テスト

回帰テストに関連性のある各種テストについても解説させていただきます。
これらのテストは直接的、あるいは間接的にテスト工程において影響します。テスト戦略を最適化することや効率よくテストを実施するうえで理解しておく必要があります。

一点目がスモークテストです。主な目標は、ビルドがテストを開始するのに十分かどうかを確認することです。例えば、URLを入力することでサイトを起動できることや、新しい実行可能ファイルをインストールした後にアプリを実行できることなど、ユーザや関係者がスムーズに操作できることを確認する作業となります。スモークテストは通常、新しいコードをチェックアウトする際の最初のステップとして実行され、ロジックのバグやデータの破損など、ソフトウェアの根本的な欠陥を特定するために使用できます。
また、大規模なシステムでは、システムのすべての機能を一度にテストするか、統合テストが必要になる場合があります。スモークテストは主に、コアコンポーネントに他の機能の正常な動作を妨げるエラーがないかどうかをチェックするため、コアダンプテストとも呼ばれるケースがあります。
二点目がサニティテストです。このテストは、新しく展開された環境での表面レベルのテストです。たとえば、機能はステージング環境で広くテストされてからユーザー受け入れテストに渡されます。フォントがWebページに正しく読み込まれていること、期待されるコンポーネントがインタラクティブであること、および全体的なものが適切に表示されていることを詳細な調査なしで確認することです。
また、サニティテストは一連のレコード内のデータに一貫性があり、エラーが含まれていないことを確認するために実行できるチェック、またはレビューの一種です。これらのテストを通して、一連のレコード内のデータが目的の結果を生成することを確認することもできます。
三点目がリグレッションテストです。リグレッションテストでは、新しい変更が導入された環境で影響を受ける可能性のある領域が徹底的にテストされます。既存の安定した機能は、定期的に厳密にテストされ、意図的および意図しない変更に直面しても正確であることを保証します。

回帰テストのアプローチ

回帰テストはいくつかのアプローチがあります。それぞれについて解説させていただきますので、参考にしてみてください。

回帰テストの主な目的は、さまざまな形でビジネスの成果に影響を与える可能性がある、使用できない機能や正しくない機能が原因でエンドユーザーが影響を受けないようにすることです。そのため、これらの実行に関しては、チームが最もビジネスに不可欠なケースと、エンドユーザーによって実行される一般的なユースケースを優先することが推奨されており、テストを実行する際には適切な戦略を柔軟に選択する必要があります。

部分回帰テスト

部分回帰テストについて説明させていただきます。
部分回帰テストは、回帰スイート全体のサブセットが選択され、回帰テストの一部として実行されるアプローチです。このサブセットの選択はいくつかの論理基準を組み合わせた結果で、具体的には、変更により影響を受ける可能性のある機能を特定することで得られたケース、ビジネスクリティカルなケース、最も一般的に使用されるパスなどがあります。
部分回帰テストは、チームが要件トレーサビリティマトリックスやチームによって承認されたその他の形式のメタデータなどの実証済みの方法を使用して、影響を受ける領域と対応するテストケースを正常に特定した場合にうまく機能します。

部分回帰テストの次の状況は、部分的な回帰テストを助長します。
一点目が多数のユニット、API、統合テスト、受け入れテストが、テストピラミッドに従って比例して配置された、堅実なテスト自動化フレームワークが用意されていることです。
二点目がソースコードへの変更は常に追跡され、機能横断的なチーム内で伝達されていることです。
三点目が予算と時間が限られている短期プロジェクトであることです。

完全な回帰テスト

完全な回帰テストについて説明させていただきます。多くの場合、重要なソフトウェアの更新、技術スタックの変更などの理由により、チームは包括的な回帰テストを実行して、新しい問題や変更によって導入された問題を発見する必要があります。完全な回帰テストによるアプローチでは、新しいコードがコミットされるたび、または合意された一定の間隔で問題を明らかにするためにテストスイート全体が実行されます。これは他の手法と比較して非常に時間がかかるアプローチであり、理想としては、必要な状況下でのみ採用する必要があります。
フィードバックサイクルをより速く維持するには、自動化されたテストを採用して、チームで生産的な完全な回帰テストを可能にする必要があります。

セキュリティテスト

セキュリティテストについて簡単に説明させていただきます。
Zed Attack Proxy (ZAP)、Wfuzz、Wapiti、W3af、SQLMap、SonarQube、Nogotofail、Iron Wasp、Grabber、およびArachniは、認証、承認、可用性、機密性、整合性などのセキュリティ条件の評価に役立つオープンソースセキュリティテストツールです。これらは両方の方法論の利点を享受するために、組織は静的アプリケーションセキュリティテスト (SAST) と動的アプリケーションセキュリティテスト (DAST) を組み合わせます。これらのいくつかのツールについても説明させていただきます。

Zed Attack Proxy (ZAP) は、Webアプリケーションの脆弱性を検出するための使いやすい統合侵入テストツールです。幅広いセキュリティ経験を持つ人々が使用するように設計されているため、侵入テストに慣れていない開発者や機能テスト担当者に最適です。 Zed Attack Proxy (ZAP) は、自動化されたスキャナーと、セキュリティの脆弱性を手動で検出できる一連のツールを提供します。
Zed Attack Proxy (ZAP) には、何千もの既知のテストケース (「ペイロード」とも呼ばれます) を含む組み込みライブラリが付属しており、最初に脆弱性を特定したり、ペイロードを記述したりすることなく、ほとんどのWebアプリケーションの脆弱性を検出できます。
Wfuzzは、Webアプリケーションの脆弱性を見つけるために使用できるセキュリティツールです。侵入テストの強力なツールとなるさまざまなオプションと機能があります。これは、Cプログラミング言語で書かれたオープンソースソフトウェアです。つまり、自由に使用および変更できます。 Wfuzzは2006年から存在していますが、ハッカーやセキュリティ研究者の間で人気を博したのはつい最近のことです。

環境と機能

回帰テストの環境と機能について説明させていただきます。アプリケーションのテストカバレッジを向上させるには、テクノロジーシナリオとビジネスシナリオを組み合わせて回帰テストを計画する必要があります。
その後テストピラミッド全体にプラクティスを適用します。

テストデータ

テストデータについて説明させていただきます。
回帰テストは自動化の力を活用して、さまざまなテスト環境でテストデータを即座に作成する必要があります。これは、更新された機能が古いデータと新しいデータの両方に対して評価されているかということを確認するためです。たとえば、ユーザープロファイルに追加された新しいフィールドは、既存のアカウントと新しく形成されたアカウントの両方で一貫して機能する必要があります。
生産テストデータは、最初の納品時に見逃された可能性のある問題を特定する上で重要な役割を果たします。運用環境を複製してエッジケースを特定し、それらのシナリオを回帰テストスイートに追加します。運用データの使用は常に実行可能とは限らず、コンプライアンス違反の問題につながる可能性があります。チームは、本番データから機密情報を頻繁に隠蔽/マスクし、その情報を使用して、現場でのシナリオ分析の要件を満たします。

自動化

自動化について説明させていただきます。
ビジネスクリティカルなシナリオや最も使用頻度の高いワークフローを単純に自動化するだけでも、効率化を図ることが可能です。このアクティビティを開始し、段階的に作業するという方法も戦略の一つです。例えば、機能に従って自動化されたシナリオにタグ付け/注釈を付けるか、適切なフォルダーに分離して、特定の自動化された回帰シナリオを実行できるようにします。
その結果、スケーラビリティ要件を満たすために、さまざまな設定での同時テスト実行が必要になります。 Selenium Gridや、 Applitools Ultrafast Test Cloudなどのその他のクラウドソリューションを使用すると、さまざまな構成で自動テストを並行して実行できます。
テスト自動化フレームワークを作成する際のベストプラクティスに従うだけでなく、これらのテストを高速かつ並行して実行して、より迅速なフィードバックを提供する必要があります。これにより自動化を最大限活用し、効率的なテストを実行することが可能となります。

大規模な回帰テスト

エンタープライズ製品は、地域を超えた複数のチームの貢献から生まれます。
チームは独自に回帰テストを実施しますが、サイロ化されたテストは避ける必要があります。チームは、すべての統合回帰シナリオをテストするために、構造やプロセスも設定する必要があります。

非機能回帰テストの計画

パフォーマンス、セキュリティ、アクセシビリティ、使いやすさなどの非機能要素は、機能に加えて回帰テスト計画の一部としてすべて調べる必要があります。
過去のセッションのテスト実行結果をベンチマークし、最新の変更後のテスト実行結果と比較することは、パフォーマンス、アクセシビリティ、およびその他の低下を検出するための単純ですが効果的な手法です。
非機能領域で重大な障害が発生したため、最高の機能を備えたアプリケーションは、正常に起動したにもかかわらず、本番環境を確認できないことが考えられます。同様に、アプリケーションのセキュリティとアクセシビリティの問題は、評判の失墜や大きな損失というリスクを負うことになります。

自動化の重要性

自動化の重要性について説明させていただきます。
アプリケーションアーキテクチャや開発方法論に関係なく、回帰テストを自動化することは非常に重要であり、それはこれからも継続することは間違いありません。これは小規模なアプリケーションであろうとエンタープライズ製品であろうと、テストを自動化することで、長期的には時間やコストを節約できます。
自動化を理解するためのポイントについて以下で説明させていただきます。

フィードバック

自動化によって素早いフィードバックが実現できます。
自動化されたソフトウェア検証は、人間よりも指数関数的に高速に実行することは間違いありません。自動化された継続的なテストは、動作の速度と頻度が向上を実現し、回帰バグを導入に近い状態で特定するための強力なアプローチです。
同様に重要なのは、自動化されたスイートの実行ごとにテスト結果を確認し、製品とテストスイートを徐々に改善するための有意義な手順を実行することです。問題をタイムリーに特定することで、アプリケーションの最も重要な部分や、テスト後の欠陥の漏えいを防ぐことができます。
これらのシフトレフトの実現は、コスト以外の多くの点で常に組織に利益をもたらします。

データの自動作成

テストデータの自動作成も大きなポイントです。
実際のテストに入る前に、テストチームはテストデータの生成に時間を費やします。自動化は、テストの実行だけでなく、大量のテストデータの迅速な生成にも役立ちます。機能テストチームは、スクリプト (SQL、API) によって生成されたデータを活用して、データについて心配することなくテストに集中できるようにします。
ページネーション、無限スクロール、表形式の表現、アプリのパフォーマンスなどのテスト機能は、迅速なテストデータの生成がチームのインスタントテストデータに役立つ例です。

まとめ

いかがでしたでしょうか？
回帰テストについて解説させていただきましたので、参考にしていただけましたら幸いです。