回帰テストとは

回帰テストは通常、バグ修正プログラムの実装後に実施され、新しいコードの追加後に機能が想定どおりに機能することを確認するためのテストを再実行することが含まれます。

回帰テストのユニークな点は、ソフトウェア開発テストのさまざまな段階を自由に行き来できる点です。回帰テストは、いつでも実施可能で、ステップを戻って、導入する新しいコードが全体的な機能とワークフローの効率に悪影響を与えていないか確認することができます。

コンピューター・コードが一貫して更新される組織は、おそらく回帰テスト手法を実装する必要があるでしょう。コードの更新は全面的に実行されるため、信頼性のある正確な総数を取得することは不可能です。

しかし、AIやCI/CDパイプラインなどのテクノロジーにより、多くの企業ではコード変更の頻度が増加しており、中には毎日全面的な更新を行っている企業もあります。これにより、多くの回帰テストが追加される可能性があります。

回帰テストが中心的な役割を担う重要な領域の1つは、品質保証（QA）の取り組みです。回帰テスト・チームとQAチームの使命は、ユーザー・エクスペリエンスを最適化し、高品質のデータと可能な限り最も安全なソフトウェアを提供するであり、非常によく似ています。

それぞれの間にある唯一の違いは、見ている全体像の範囲です。回帰テストは、最近行われた変更に焦点を当てるためにより正確な範囲を使用し、QAはシステム全体とその動作を評価します。

回帰テスト手法は、コード変更をホストするシステムとの互換性に欠けるコード変更に対するバックストップとして機能します。システム・オペレーションを最適に保つには、このような対策を講じることが重要です。

回帰テストでは、通常、次の一連のステップ（またはそれにほぼ同様のステップ）に従います。

1. コード変更を導入する： ソースコード内に新しいコードを追加したり、既存のコードを修正したり、現在の機能を最適化したりします。
2. 考えられる影響を検討する：ソフトウェア・アプリケーションを分析して、新しい変更の影響を受ける可能性のある領域を特定します。
3. テスト・ケースの選択：DevOpsチームは、回帰テスト・スイート内のテスト・ケースに基づいてテストを選択し、特に重要な機能をカバーするテスト・ケースに重点を置きます。ユニット・テスト（個々のモジュール用）、機能テスト（操作の検証用）、統合テスト（コンポーネントが連携して動作することを確認）などが含まれます。
4. テスト・ケースに優先順位をつける：複数のテストケースが選択された場合、チームはテストケースの優先順位付けを行い、重要性と潜在的な影響に基づいて整理します。
5. テストケースの実行：テストを手動で実行するか、自動回帰テストツールを使用します。利用するアプローチにかかわらず（たとえば、手動テストと自動テスト）、テスト・スクリプト（テスト実施者の行動をガイドする構造化されたテンプレート）に依存します。
6. テスト結果の報告と分析： テストの結果と補足データを確認します。テストでバグや障害が発見された場合は、すぐに開発チームに通知します。
7. 修正とケースの再テスト：開発者は既存のテスト・ケースに必要な修正を適用し、以前にフラグが付けられた問題を再テストして解決を確認します。
8. 必要に応じて、全プロセスを繰り返す：Webアプリケーションが意図したとおりに動作することを確実にするために、必要な回数だけ回帰テストのサイクルを繰り返します。

一見わかりやすいトピックですが、回帰テストでは数多くの手法が使われています。それぞれの回帰テストに独自の特徴があります。

その名前が示すように、この形式の回帰テストは、システムを構成するコンポーネントまたはモジュール（または「ユニット」）と、その個々のユニットにエラーが発生しているかどうかに重点を置きます。

例：開発者は、「パスワードを忘れた」機能をWebサイトに追加することを決定する場合があります。ユニット回帰テストでは、追加機能があっても、元のログイン・メカニズムが意図したとおりに動作し続けるかどうかを確認します。

最近の変更が、更新されたシステムのサブセットだけに影響を与えたかどうかを調べることが目的である場合、部分回帰テストは、そのサブセットを検出し、適切な診断を実行するために使用されます。

例：ウェブサイトが新しい決済ゲートウェイを統合する場合。部分回帰テストでは、新しい機能の一部とその専用性だけが評価されるため、より多くの無関係な機能がテストされないままになる場合があります。

大規模なコード変更後などは、より包括的なテストが必要になる場合もあります。完全回帰テストには、システム全体またはアプリケーション全体を再テストして、継続的な機能を確認することが含まれます。

例：Webサイトの開発者が、厳選した商品のギャラリーを掲載する場合。作成されると、会社は新しいギャラリーの機能と既存のすべてのテスト・ケースの機能に対して完全な回帰テストを実行します。これらはすべて再実行が必要です。

選択的回帰テストでは、回帰テストに予測要素が導入されます。その中で、テスト・スイートのテスト・ケースは、その領域がコード変更の影響を受けるというテスターの考えに基づいて選択されます。

例：モバイル・アプリケーションの開発者は、ユーザー・インターフェースの一部の要素を統合して更新する必要があることに気づいたとします。このような場合、開発者は選択的回帰テストを採用して、ユーザー・インターフェースの継続的な安定性を確保することができます。

テストにおける混合アプローチの一種で、新機能と既存機能の両方を評価します。進歩的回帰テストでは、新しい機能によってもたらされたバグを検知するためにそれぞれをチェックします。

例：既存のソフトウェア製品に新しいアップデートをリリースするたびに、組織は通常、事前に進歩的回帰テストを実施し、最新のアップデートの機能がシリーズによって提示された機能を反映し続けていることを確認します。

データの一貫性を確保することが、修正回帰テストのポイントです。テスト・ケースを再実行することで、同様のテスト結果が発生するかどうかを確認します。修正回帰テストは、多くの場合、コードベースに変更が加えられていない場合に実施されます。

例：新たな機能とは、必ずしもソフトウェアに追加されるものとは限りません。コードを改良し、動作を改善するために変更が加えられることがあります。修正回帰テストは、コードがリファクタリングされ、そのリファクタリングがコード・エラーを引き起こさないことを確認する場合に使用されます。

総合再回帰テストは、最終テスト後に検討されます。これには、開発チームが、全体的な調和と連携を確認するために、すでにクリアしているすべての回帰テスト・ケースでテストを実行することが含まれます。

例：再回帰テストは、ソフトウェアの主要なアーキテクチャー変更に伴う変更のチェックによく使用されます。例えば、オペレーションの大幅な変更を伴う新しいフレームワークを採用する金融系アプリなどです。

ここで説明する種類のテストには時間がかかる場合があるため、プロセスを加速するために自動テスト・ツールが導入されることがよくあります。大規模なシステムが関係している場合でも、テスト実行速度が加速します。

例：バックエンドの更新後に自動回帰テストを使用して、アプリケーション・プログラミング・インターフェース（API）エンドポイントが正しいデータと応答を生成し続け、全体的なオペレーションが正しいかどうかを確認できます。

特定のテスト・シナリオでは人間の理解が必要であり、そこで手動回帰テストが実施されます。手動テストは、業務において情報を得るために特別な注意を払うため、通常、より多くの時間が必要になると考えられます。

例：Webサイトは、様々なプラットフォーム上で見栄えよく、かつ比較可能である必要があります。手動回帰テストを使用すると、レイアウト変更後のWebサイトの応答性をチェックできます。

この回帰テストでは、オープンソースの Web自動化フレームワークであるSeleniumを活用します。Selenium回帰テストは、回帰を早期に検出し、新しい変更が既存のコードに影響を与えないようにすることで、ソフトウェアの安定性を高めます。継続的インテグレーションなど、更新が頻繁に行われる状況で特に役立ちます。

例：航空券予約システムが、これまで可能だったクレジットカード決済に加え、デビットカード決済を可能にする新機能を追加した場合。Seleniumは、クレジットカード決済の流れが期待どおりに機能し続けることを検証できます。

ソフトウェアの品質は、ソフトウェア開発ライフサイクル（SDLC）とは別に存在するいくつかの変数によって判断されます。非機能的回帰テストは、安全に使用でき、優れたユーザー・エクスペリエンスをサポートする高品質のソフトウェアの存在について検証することを目的としています。

例：Webサイトの開発者が新たな機能を追加し、その機能が動作速度にどのような影響を与えるかを判断したい場合。非機能回帰テストでは、読み込み時間がチェックされます。読み込み時間が増加した場合は、回帰を示します。

回帰テストのもう一つの重要な側面は、他のテストスキームとどのように連携して相乗効果を生み出せるのか、という点です。以下に、その一部を紹介します。

• 探索的テスト：探索的テストを回帰テストと組み合わせると、分析に活用できるより多くの結果が得られます。この2つは動作が異なります。回帰テストはスクリプト・テストを使用した後に予想されるシステム動作を確認するためのもので、探索的テストはスクリプト化されていない開発者による調査を通じて予期しない問題を特定するものです。とはいえ、この2つのテスト・スキームを補完的に使用して、それぞれがお互いに情報を供給できます。組織によっては、開発者に方向性を示しながら柔軟性を高めるために、2つの方法を全面的に組み合わせた探索的回帰テストを用います。その中で、探索的テストは、既存のケースや新しいテストケースを改善し、より包括的なテストカバレッジを促進するために役立ちます。

• 継続的テスト：同様に、回帰テストは継続的テストと併用されることがよくあります。その名前が示すように、継続的テストでは、継続的なテスト手法を全体のSDLCに統合する必要があります。継続的テストは、回帰テストの一部として確立されています。回帰テストは、継続的なテストなしでは意図したとおりに動作しませんでした。この2つを組み合わせた継続的回帰トレーニングにより、テスターは、バグやその他の問題が発生する可能性のある優先度の高いテスト環境に焦点を絞る際に、より自由に作業できます。

• エンド・ツー・エンド・テスト：回帰テストで使用されるもう1つのテクノロジーはエンドツーエンド（E2E）テストです。これは、現実的なユーザー・シナリオを実装して、システムのワークフロー全体を網羅的に（エンド・ツー・エンドで）検証するものです。E2Eは、ユーザー・エクスペリエンスだけでなく、インターフェース、バックエンド、関連データベースなどのコンポーネントにも重点を置いています。回帰テストとE2Eは補完的な取り組みであり、回帰テストにはE2Eテスト全体を含めることができ、E2Eテストは回帰テストを通じて修復が必要な問題の存在を示すことができます。

AIの広範な影響は驚くべきものです。テクノロジー業種ほどAIに多額の投資を行っている業種はほとんどありません。回帰テストは、AIの力によって原理的に高速化している多くの技術的プロセスの1つです。

「高速化」というフレーズが適切な理由として、AIが回帰テストを強化する主な方法が、さまざまな結論に達する速度を最大化することだという点が挙げられます。ただし、AIはそのテストデータの精度も向上させています。

具体的には、AIはアルゴリズムを使用して過去のテスト・データ、ユーザーの行動、コードの変更を分析することで、関連するテスト・ケースを構築します。これは、予測される影響に応じてテストの優先順位を付ける際に役立ちます。そして、AIがこれらのテストを実行すると、より高速に実行され、より迅速に結果が得られます。

AIは、欠陥検知メソッドや自己修復テストを使用することで、回帰テストの性質と品質も強化します。これにより、開発が継続する状況であっても、自動テストを適切に機能させ続けることができます。最終的には、AIは意思決定を強化しタスクを自動化することで回帰テストを改善し、それによってコストを削減し、市場投入までの時間を短縮します。